llvm-svn: 153911

llvm-svn: 153910

Fixed an issue where there were more than one way to get a CompileUnitSP created when using SymbolFileDWARF with SymbolFileDWARFDebugMap. This led to an assertion that would fire under certain conditions. Now there is only one way to create the compile unit and it will "do the right thing".

llvm-svn: 153908

llvm-svn: 153907

llvm-svn: 153899

Export the ability to see if a symbol is externally visible and also if the symbol was synthetically added to the symbol table (the symbol was not part of the symbol table itself but came from another section).

llvm-svn: 153893

rdar://problem/11167268

llvm-svn: 153891

llvm-svn: 153878

with some archs, tweak the way we update PATH to fix that.

llvm-svn: 153868

llvm-svn: 153823

JIT that enables paired relocations in the i386
Mach-O JIT.  This eliminates crashes in the
testsuite when running under i386.

llvm-svn: 153822

Making sure the count on synthetic providers is always setup - This should prevent errors about count being undefined from showing up

llvm-svn: 153791

llvm-svn: 153790

(lldb) log enable --verbose lldb completion

This will print out backtraces for all type completion calls which will help us verify that we don't ever complete a type when we don't need to.

llvm-svn: 153787

llvm-svn: 153786

llvm-svn: 153785

Fixed a potential crasher that could happen after Debugger::Terminate() was called.

llvm-svn: 153774

Patch from Viktor Kutuzov: fixes a segmentation fault crash in lldb in the ProcessPOSIX class when the object gets destroyed. I can reproduce this problem on the FreeBSD platform and it should be reproducable for the other platforms also.

llvm-svn: 153769

Disabling blocks support because of rdar://problem/11024417 - This is hopefully just a temporary countermeasure

llvm-svn: 153758

Added some logging to STL synthetic children providers - this should help us catch problems; more logging might/will be added as needed

llvm-svn: 153750

ValueObject, and make sure that ValueObjects that
have null type names (because they have null types)
also have null qualified type names.  This avoids
some potential crashes if 
ValueObject::GetQualifiedTypeName tries to get the
name of their type by calling GetClangTypeImpl().

llvm-svn: 153718

Fixed an issue that could cause circular type parsing that will assert and kill LLDB.

Prior to this fix the DWARF parser would always create class types and not start their definitions (for both C++ and ObjC classes) until we were asked to complete the class later. When we had cases like:

class A
{
    class B
    {
    };
};

We would alway try to complete A before specifying "A" as the decl context for B. Turns out we can just start the definition and still not complete the class since we can check the TagDecl::isCompleteDefinition() function. This only works for C++ types. This means we will not be pulling in the full definition of parent classes all the time and should help with our memory consumption and also reduce the amount of debug info we have to parse.

I also reduced redundant code that was checking in a lldb::clang_type_t was a possible C++ dynamic type since it was still completing the type, just to see if it was dynamic. This was fixed in another function that was checking for a type being dynamic as an ObjC or a C++ type, but there was dedicated fucntion for C++ that we missed.

llvm-svn: 153713

Fixing a whole class of crashers and potential crashers related to data formatters eating up all the stack when an unknown class has to be summarized ; this should make the whole Objective-C summaries more stable

llvm-svn: 153712

llvm-svn: 153695

Symbol files (dSYM files on darwin) can now be specified during program execution:

(lldb) target symbols add /path/to/symfile/a.out.dSYM/Contents/Resources/DWARF/a.out

This command can be used when you have a debug session in progress and want to add symbols to get better debug info fidelity.

llvm-svn: 153693

Line tables when using DWARF in .o files can be wrong when two entries get moved around by the compiler. This was due to incorrect logic in the line entry comparison operator.

llvm-svn: 153685

llvm-svn: 153683

Part 1 of a series of fixes meant to improve reliability and increase ease of bug fixing for data formatter issues.
We are introducing a new Logger class on the Python side. This has the same purpose, but is unrelated, to the C++ logging facility
The Pythonic logging can be enabled by using the following scripting commands:
(lldb) script Logger._lldb_formatters_debug_level = {0,1,2,...}
0 = no logging
1 = do log
2 = flush after logging each line - slower but safer
3 or more = each time a Logger is constructed, log the function that has created it
more log levels may be added, each one being more log-active than the previous
by default, the log output will come out on your screen, to direct it to a file:
(lldb) script Logger._lldb_formatters_debug_filename = 'filename'
that will make the output go to the file - set to None to disable the file output and get screen logging back
Logging has been enabled for the C++ STL formatters and for Cocoa class NSData - more logging will follow


synthetic children providers for classes list and map (both libstdcpp and libcxx) now have internal capping for safety reasons
this will fix crashers where a malformed list or map would not ever meet our termination conditions

to set the cap to a different value:

(lldb) script {gnu_libstdcpp|libcxx}.{map|list}_capping_size = new_cap (by default, it is 255)

you can optionally disable the loop detection algorithm for lists

(lldb) script {gnu_libstdcpp|libcxx}.list_uses_loop_detector = False

llvm-svn: 153676

for unbacked properties.  We support two variants:
one in which the getter/setter are provided by
selector ("mySetter:") and one in which the
getter/setter are provided by signature 
("-[MyClass mySetter:]").

llvm-svn: 153675

llvm-svn: 153662

llvm-svn: 153661

llvm-svn: 153630

<rdar://problem/11051056>

Found a race condition when sending async packets in the ProcessGDBRemote.

A little background: GDB remote clients can only send one packet at a time. You must send a packet and wait for a response. So when we continue, we obviously can't hold up the calling thread waiting for the process to stop again, so we have an async thread in the ProcessGDBRemote whose only job is to run packets that control the inferior process. When you send a continue packet, the only packet you can send is an interrupt packet (which consists of sending a CTRL+C (or a '\x03' byte)). This then stops the inferior and we can send the async packet, and then resume the target. There was a race condition that often happened during stepping where we are doing a source level single step which consists of many instruction steps and a few runs here and there when we step into a function. So the flow looks like:

inst single step
inst single step
inst single step
inst single step
inst single step
step BP and run
inst single step
inst single step
inst single step

Now if we got an async packet while the program is running we get something like:

send --> continue
send --> interrupt
recv <-- interrupt stop reply packet
send --> async packet
recv <-- async response
send --> continue again and wait for actual stop

Problems arise when this was happening when single stepping a thread where we would get:

send --> step thread 123
send --> interrupt
send --> stop reply for thread 123 (from the step)

Now we _might_ have an extra stop reply packet from the "interrupt" which we weren't checking for and we could end up with:

send --> async packet (like memory read!)
recv <-- async response (which is the interrupt stop reply packet)

Now we have the read memroy reply sitting in our buffer and waiting to be used as the reply for the next packet... 

To further complicate things, the single step should have exited the async thread since the run control is finished, but now it will continue if it was interrupted.

The fixes I checked in to two major things:
- watch for the extra stop reply if we need to
- make sure we exit from the async thread run loop when the previous run control (like the instruction level single step) is finished.

Needless to say this makes very fast stepping in Xcode much more reliable.

llvm-svn: 153629

Fixed an issue with stepping where the stack frame list could get changed out from underneath you when multiple threads start accessing frame info.

llvm-svn: 153627

When running this from the command line, don't pass the python script file itself to be disassembled.

llvm-svn: 153626

llvm-svn: 153625

Fixing an issue where Unicode characters in an NSString were printed as escape sequences by the summary provider shipping with LLDB - Added relevant test case code. Bonus points for identifying the source of the quotes :-)

llvm-svn: 153624

Fixing an issue where saying 'po foo' made both the summary and the description for foo come out. If one is po'ing something they most probably only care about the description - We will not omit the summary

llvm-svn: 153608

Converted commented out printf statements for dynamic type logging to use the log for "log enabe lldb types".

llvm-svn: 153583

llvm-svn: 153582