Ensure that lldb/runtime is not a dead point in the Python package hierarchy - This is a first preliminary step in fixing data formatters after Greg's changes to the Python resources on-disk layout

llvm-svn: 155525

llvm-svn: 155524

llvm-svn: 155523

llvm-svn: 155521

llvm-svn: 155520

llvm-svn: 155517

llvm-svn: 155516

ObjCPlusPlus as Objective-C classes.  Really the
compiler should say they have Objective-C runtime
class, but we should be a little more resilient
(we were refusing to find ivars in those classes
before).

Also added a test case.

llvm-svn: 155515

Enrico will follow this up with fixing the data formatter test cases that are failing.

llvm-svn: 155514

the same test to be run multiple times in the same
session.

llvm-svn: 155511

llvm-svn: 155510

if the section is marked as encrypted.  It will likely be readable
in live memory.
<rdar://problem/11305675>

llvm-svn: 155509

rdar://problem/11312971

llvm-svn: 155505

test whether an object responds to a selector
from outside the process.

llvm-svn: 155504

case so that the Objective-C runtime doesn't
complain about lack of one, causing the test case
to fail.

llvm-svn: 155503

llvm-svn: 155501

llvm-svn: 155497

Fixing an issue where the expression parser was not correctly freeze-drying bitfields - This patch ensures that (a) freeze-drying bitfields works correctly and (b) that we actually access bitfields through IR instead of the 'frame var en lieu of expr' shortcut, for added safety in corner cases that may arise

llvm-svn: 155494

Add a '-R' option, which is similar to '-r', except that the relocated directory, if exists, will be removed entirely
before running the test suite.  A usage example looks like this:

test $ ./dotest.py -A x86_64 -R /tmp/x86_64 &
test $ ./dotest.py -A i386 -R /tmp/i386 &

where we would want to run the x86_64 and i386 archs concurrently but relocate the test suite to different directory
hierarchies in order not to stump on each other's intermediate files.

llvm-svn: 155491

Fixed an issue that would happen when using debug map with DWARF in the .o files where we wouldn't ever track down the actual definition for a type when things were in namespaces. We now serialize the decl context information into an intermediate format which allows us to track down the correct definition for a type regardless of which DWARF symbol file it comes from. We do this by creating a "DWARFDeclContext" object that contains the DW_TAG + name for each item in a decl context which we can then use to veto potential accelerator table matches. For example, the accelerator tables store the basename of the type, so if you have "std::vector<int>", we would end up with an accelerator table entry for the type that contained "vector<int>", which we would then search for using a DWARFDeclContext object that contained:

  [0] DW_TAG_class_type "vector<int>"
  [1] DW_TAG_namespace "std"

This is currently used to track down forward declarations for things like "class a::b::Foo;". 

llvm-svn: 155488

doesn't return a result.  If that expression can't
be run in the current context (for example, if it
uses a function and there is no running process)
then we used to try to destroy the nonexistent
result variable.  We now only destroy the result
variable if we actually made one.

llvm-svn: 155455

llvm-svn: 155423

llvm-svn: 155422

into the middle of a vector was being used after the vector may
have been resized.  
<rdar://problem/11284937>

llvm-svn: 155421

llvm-svn: 155420

Removing the @expectedFailurei386 decorator from test cases that now work as a result of the latest changes to Value.cpp

llvm-svn: 155419

This patch fixes a bug where LLDB was incorrectly setting the address-size on a DataExtractor to be sizeof(void*) when the ValueObject came out of the expression parser
This worked correctly for 64-bit targets, but broke down data formatters in i386 mode. The formatters would try to read pointers out of the frozen-dried objects,
but were unable to do so because they would try fetching 8 bytes from a DataExtractor with only 4 bytes in it. This patch fixes the issue by always making the pointer-size
for a DataExtractor match the target setting.

llvm-svn: 155418

llvm-svn: 155407

Added the ability to log a message with a backtrace when verbose logging is enabled to the Module class. Used this new function in the DWARF parser.

llvm-svn: 155404

Fixed an issue where we get NULL compile units back from the symbol vendor. We need symbol vendors to be able to quickly give an estimate of the compile units that they have without having to fully vette them first, so anyone getting compile units from a module should be able to deal with a NULL compile unit being returned for a given index.

llvm-svn: 155398

llvm-svn: 155384

llvm-svn: 155369

interpreter.

llvm-svn: 155360

llvm-svn: 155272

llvm-svn: 155264

Added code to automatically load the libheap.dylib when ptr_refs, cstr_refs or malloc_info are called. If MallocStackLogging is enabled, then you can now use --stack to dump the backtrace of the code that allocated each malloc block.

llvm-svn: 155262

llvm-svn: 155260

Fixed some issues with symbolicating things. Fixed symbolication.add_module() to not use the resolved_path before we have tried to locate it. Fixed crashlog.locate_module_and_debug_symbols() to return true and false correctly.

llvm-svn: 155255

Make sure the "synchronous breakpoint callbacks" get called before the thread plan logic gets invoked, and if they
ask to continue that should short-circuit the thread plans for that thread.  Also add a bit more explanation for
how this machinery is supposed to work.  
Also pass eExecutionPolicyOnlyWhenNeeded, not eExecutionPolicyAlways when evaluating the expression for breakpoint
conditions.

llvm-svn: 155236

Added logging so we can see when we are trying to complete a forward type and pull in the world. This is due to a compiler bug we are tracking (<rdar://problem/11291658>) where forward decls to classes and types are not properly scoped in namespaces, which results in the current LLDB looking for a type it will find many times in the accelerator tables, but never match. For example, when debugging with clang we get a forward decl like:

class AnalysisResolver;

And we will look for it everywhere and find many many matches, but the decl context of those matching DIEs is "clang::AnalysisResolver", so we never match anything, yet we pull in waaayyy too much DWARF in the process.

To enable this logging enable the "lookups" category in the "dwarf" log channel:

(lldb) log enable dwarf lookups

llvm-svn: 155233