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

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