Automatically enabling the Cocoa formatter categories for command-line LLDB. Previously, the categories were filled in but disabled by default. Tweaking test cases appropriately to keep working and do the right thing

llvm-svn: 155605

<rdar://problem/11285931>

Use the DWARRF end prologue markers when trying to skip prologue instructions instead of blindly using the second line table address entry.

llvm-svn: 155600

Patch from Viktor Kutuzov: changes the method declarations to const for the Args::GetCommandString and Agrs::GetQuotedCommandString methods. It allows using of these methods within the other const methods.

llvm-svn: 155593

Make sure the end of the first line is still within the function, and if not, don't push the prologue past it.

rdar://problem/11271074

llvm-svn: 155579

Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing

llvm-svn: 155563

into FindExternalVisibleDeclsByName.

llvm-svn: 155561

Now that we have an LLDB package, make the "lldb.macosx.crashlog" module work with all of the new module paths.

llvm-svn: 155528

llvm-svn: 155527

Making the Cocoa formatters comply with the new on-disk layout of the Python resources - This is one of the steps towards making the data formatters work again

llvm-svn: 155526

llvm-svn: 155517

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

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

llvm-svn: 155509

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

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

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

interpreter.

llvm-svn: 155360

llvm-svn: 155272

llvm-svn: 155260

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

Don't put the address of the module in the module basename as this hoses up our ability to find shared libraries by name. We now put it into the Module object name.

llvm-svn: 155223

Fixed an issue where iOS debugging would trust the first file it found in the SDK regardless of the UUID not matching. Now we actually get smart and can find modules in ANY of the installed SDKs and remember which SDK is our fallback SDK.

llvm-svn: 155184

llvm-svn: 155175

In debug mode, assert when we fail to get the sequence mutex.  We need to remove as many places where this can happen as possible.

llvm-svn: 155138

llvm-svn: 155093

Switch to setting the write side of the run lock when we call Resume.  Then make a PrivateResume that doesn't switch the run-lock state, and use that where we are resuming without changing the public resume state.

llvm-svn: 155092

for the plan stack, so assert here if it gets called with an empty plan stack.
<rdar://problem/11265974>

llvm-svn: 155078

llvm-svn: 155077

Make sure EmulateInstructionARM doesn't have to have "armv4", "armv6", "armv7" as the exact architecture name, the arch name can just start with any of these strings. We need to be able to recognize different variants that might come along and not fail to backtrace completely (which happens when we aren't able to find an architecture that matches) when we don't have exact matches.

llvm-svn: 155045

Added an iOS local debugging optimization when reading the __LINKEDIT section data for files in the dyld shared cache.

llvm-svn: 154984

Find and allows users to use the cached SDK's that might be in "~/Library/Developer/Xcode/iOS DeviceSupport".
Also enabled PlatformRemoteiOS to select an SDK using the build number in case you have mutliple 5.0 SDKs installed:

(lldb) platform select remote-ios --build 11C123

llvm-svn: 154978