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

with recent Clang.  Clang is now stricter about
presence of complete types and about use of the
"template" keyword in C++ for template-dependent
types.

llvm-svn: 153563

llvm-svn: 153559

llvm-svn: 153541

llvm-svn: 153540

indicates that the section is thread specific. Any functions the load a module
given a slide, will currently ignore any sections that are thread specific.

lldb_private::Section now has:

bool
Section::IsThreadSpecific () const
{
    return m_thread_specific;
}

void
Section::SetIsThreadSpecific (bool b)
{
    m_thread_specific = b;
}

The ELF plug-in has been modified to set this for the ".tdata" and the ".tbss"
sections.

Eventually we need to have each lldb_private::Thread subclass be able to 
resolve a thread specific section, but for now they will just not resolve. The
code for that should be trivual to add, but the address resolving functions
will need to be changed to take a "ExecutionContext" object instead of just
a target so that thread specific sections can be resolved.

llvm-svn: 153537

1 - sections only get a valid VM size if they have SHF_ALLOC in the section flags
2 - symbol names are marked as mangled if they start with "_Z"

Also fixed the DWARF parser to correctly use the section file size when extracting the DWARF.

llvm-svn: 153496

Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available.
A new setting enable-synthetic-value is provided on the target to disable this behavior.
There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic.
The test suite has been changed accordingly.
Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang
Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching

llvm-svn: 153495

Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). 

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

llvm-svn: 153482

If creation of watchpoint failed on the device, make sure the list maintained by the target reflects that by cleaning it up.

llvm-svn: 153477

Patched LLVM to handle generic i386 relocations.
This avoids some sudden termination problems on
i386 where the JIT would exit() out reporting
"Invalid CPU type!"

llvm-svn: 153467

if it's there and we may not have a cached die yet. This
fixes a bunch of false positives on "die has no decl".

llvm-svn: 153417

llvm-svn: 153416

llvm-svn: 153374

llvm-svn: 153371

llvm-svn: 153365

Adding a new API call IsTypeComplete() to SBType. This call is meant to check if the type has been previously completed or not (which is mostly interesting from a performance point of view)

Adding a test case that checks that we do not complete types before due time. This should help us track cases similar to the cascading data formatters.

llvm-svn: 153363

We now reject binaries built with LTO and print
an error, rather than crashing later while trying
to parse them.

llvm-svn: 153361

llvm-svn: 153301

We do this by delegating to two available Watchpoint Register Pairs (wvr, wcr).  With
each pair handling the 4 bytes of (uint64_t)variable.

llvm-svn: 153300

llvm-svn: 153298

Fixed up the command so that it doesn't dump the first arguments when run from the command line which was causing this script to dump the script itself.

llvm-svn: 153294

parse the output from "log enable --timestamp ...." and converts it to be relative
to the first timestamp and shows the time deltas between log lines. This can also
be used as a stand along script outside of lldb:

./delta.py log.txt

llvm-svn: 153288