the debug information individual Decls came from.
We've had a metadata infrastructure for a while,
which was intended to solve a problem we've since
dealt with in a different way. (It was meant to
keep track of which definition of an Objective-C
class was the "true" definition, but we now find
it by searching the symbols for the class symbol.)
The metadata is attached to the ExternalASTSource,
which means it has a one-to-one correspondence with
AST contexts.
I've repurposed the metadata infrastructure to
hold the object file and DIE offset for the DWARF
information corresponding to a Decl. There are
methods in ClangASTContext that get and set this
metadata, and the ClangASTImporter is capable of
tracking down the metadata for Decls that have been
copied out of the debug information into the
parser's AST context without using any additional
memory.
To see the metadata, you just have to enable the
expression log:
-
(lldb) log enable lldb expr
-
and watch the import messages. The high 32 bits
of the metadata indicate the index of the object
file in its containing DWARFDebugMap; I have also
added a log which you can use to track that mapping:
-
(lldb) log enable dwarf map
-
This adds 64 bits per Decl, which in my testing
hasn't turned out to be very much (debugging Clang
produces around 6500 Decls in my tests). To track
how much data is being consumed, I've also added a
global variable g_TotalSizeOfMetadata which tracks
the total number of Decls that have metadata in all
active AST contexts.
Right now this metadata is enormously useful for
tracking down bugs in the debug info parser. In the
future I also want to use this information to provide
more intelligent error messages instead of printing
empty source lines wherever Clang refers to the
location where something is defined.
llvm-svn: 154634
FunctionDecls into classes if it looked up a
method in a different DWARF context than the
one where it found the parent class's definition.
The symptom of this was, for a method A::B(),
1) LLDB finds A in context 1, creating a
CXXRecordDecl for A and marking it as needing
completion
2) LLDB looks up B in context 2, finds that its
parent A already has a CXXRecordDecl, but can't
find a CXXMethodDecl for B
3) Not finding a CXXMethodDecl for B, LLDB doesn't
set the flag indicating that B was resolved
4) Because the flag wasn't set, LLDB's fallthrough
code creates a FunctionDecl for B and sticks it
in the DeclContext -- in this case, A.
5) Clang crashes on finding a FunctionDecl inside a
CXXRecordDecl.
llvm-svn: 154627
(lldb) command script import heap.py
Find all malloc blocks that contains a pointer value of 0x1234000:
(lldb) ptr_refs 0x1234000
Find all malloc blocks that contain a C string:
(lldb) cstr_refs "hello"
Get info on a malloc block that starts at or contains 0x12340000
(lldb) malloc_info 0x12340000
llvm-svn: 154602
for packet confirmation.
Also added a bit more logging.
Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state
thread so that the Process can shut down cleanly.
<rdar://problem/11228538>
llvm-svn: 154601
First we can load the module:
(lldb) command script import /Volumes/work/gclayton/Documents/src/lldb/examples/darwin/heap_find/heap.py
Loading "/Volumes/work/gclayton/Documents/src/lldb/examples/darwin/heap_find/libheap.dylib"...ok
Image 0 loaded.
"heap_ptr_refs" and "heap_cstr_refs" commands have been installed, use the "--help" options on these commands for detailed help.
Lets take a look at the variable "my":
(lldb) fr var *my
(MyString) *my = {
MyBase = {
NSObject = {
isa = MyString
}
propertyMovesThings = 0
}
str = 0x0000000100301a60
date = 0x0000000100301e60
_desc_pauses = NO
}
We can see that this contains an ivar "str" which has a pointer value of "0x0000000100301a60". Lets search the heap for this pointer and see what we find:
(lldb) heap_ptr_refs 0x0000000100301a60
found pointer 0x0000000100301a60: block = 0x103800270, size = 384, offset = 168, type = 'void *'
found pointer 0x0000000100301a60: block = 0x100301cf0, size = 48, offset = 16, type = 'MyString *', ivar = 'str'
(MyString) *addr = {
MyBase = {
NSObject = {
isa = MyString
}
propertyMovesThings = 0
}
str = 0x0000000100301a60
date = 0x0000000100301e60
_desc_pauses = NO
}
found pointer 0x0000000100301a60: block = 0x100820000, size = 4096, offset = 96, type = (autorelease object pool)
found pointer 0x0000000100301a60: block = 0x100820000, size = 4096, offset = 104, type = (autorelease object pool)
Note that it used dynamic type info to find that it was in "MyString" at offset 16 and it also found the ivar "str"!
We can also look for C string values on the heap. Lets look for "a.out":
(lldb) heap_cstr_refs "a.out"
found cstr a.out: block = 0x10010ce00, size = 96, offset = 85, type = '__NSCFString *'
found cstr a.out: block = 0x100112d90, size = 80, offset = 68, type = 'void *'
found cstr a.out: block = 0x100114490, size = 96, offset = 85, type = '__NSCFString *'
found cstr a.out: block = 0x100114530, size = 112, offset = 97, type = '__NSCFString *'
found cstr a.out: block = 0x100114e40, size = 32, offset = 17, type = '__NSCFString *'
found cstr a.out: block = 0x100114fa0, size = 32, offset = 17, type = '__NSCFString *'
found cstr a.out: block = 0x100300780, size = 160, offset = 128, type = '__NSCFData *'
found cstr a.out: block = 0x100301a60, size = 112, offset = 97, type = '__NSCFString *'
found cstr a.out: block = 0x100821000, size = 4096, offset = 100, type = 'void *'
We see we have some objective C classes that contain this, so lets "po" all of the results by adding the --po option:
(lldb) heap_cstr_refs a.out --po
found cstr a.out: block = 0x10010ce00, size = 96, offset = 85, type = '__NSCFString *'
(__NSCFString *) 0x10010ce00 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out
found cstr a.out: block = 0x100112d90, size = 80, offset = 68, type = 'void *'
found cstr a.out: block = 0x100114490, size = 96, offset = 85, type = '__NSCFString *'
(__NSCFString *) 0x100114490 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out
found cstr a.out: block = 0x100114530, size = 112, offset = 97, type = '__NSCFString *'
(__NSCFString *) 0x100114530 Hello from '/Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out'
found cstr a.out: block = 0x100114e40, size = 32, offset = 17, type = '__NSCFString *'
(__NSCFString *) 0x100114e40 a.out.dSYM
found cstr a.out: block = 0x100114fa0, size = 32, offset = 17, type = '__NSCFString *'
(__NSCFString *) 0x100114fa0 a.out
found cstr a.out: block = 0x100300780, size = 160, offset = 128, type = '__NSCFData *'
(__NSCFData *) 0x100300780 <48656c6c 6f206672 6f6d2027 2f566f6c 756d6573 2f776f72 6b2f6763 6c617974 6f6e2f44 6f63756d 656e7473 2f737263 2f6c6c64 622f7465 73742f6c 616e672f 6f626a63 2f666f75 6e646174 696f6e2f 612e6f75 742700>
found cstr a.out: block = 0x100301a60, size = 112, offset = 97, type = '__NSCFString *'
(__NSCFString *) 0x100301a60 Hello from '/Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out'
found cstr a.out: block = 0x100821000, size = 4096, offset = 100, type = 'void *'
llvm-svn: 154519
Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.
Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.
llvm-svn: 154458
QListThreadsInStopReply
This GDB remote query command can enable added a "threads" key/value pair to all stop reply packets so that we always get a list of all threads in each stop reply packet. It increases performance if enabled (the reply to the "QListThreadsInStopReply" is "OK") by saving us from sending to command/reply pairs (the "qfThreadInfo" and "qsThreadInfo" packets), and also helps us keep the current process state up to date.
llvm-svn: 154380
The next step is to have our stop reply packets send the thread list in the actual stop reply packet to avoid a 2 packet overhead of sending the qfThreadInfo + response and qfThreadInfo + response.
llvm-svn: 154376
1) Start the PrivateStateThread stopped, and then in
StartPrivateStateThread, make the private state thread and then
resume it before we say the thread is created. That way we know it is
listening for events by the time we get out of
StartPrivateStateThread.
2) Backstop running a thread plan when calling Process::RunThreadPlan
on the private state thread with a ThreadPlanBase so that running the
plan doesn't pass its stop events to whatever plans happen to be above
us on the thread plan stack.
llvm-svn: 154368
The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the:
virtual bool
Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list,
lldb_private::ThreadList &new_thread_list) = 0;
A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned.
The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue.
llvm-svn: 154365
Work around a deadlocking issue where "SBDebugger::MemoryPressureDetected ()" is being called and is causing a deadlock. We now just try and get the lock when trying to trim down the unique modules so we don't deadlock debugger GUI programs until we can find the root cause.
llvm-svn: 154339
nanoseconds in 32-bit expression would cause pthread_cond_timedwait
to time out immediately. Add explicit casts to the TimeValue::TimeValue
ctor that takes a struct timeval and change the NanoSecsPerSec etc
constants defined in TimeValue to be uint64_t so any other calculations
involving these should be promoted to 64-bit even when lldb is built
for 32-bit.
<rdar://problem/11204073>, <rdar://problem/11179821>, <rdar://problem/11194705>.
llvm-svn: 154250
spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do
that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference.
This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug
server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call.
llvm-svn: 154230
new features:
(1) it outputs the instruction currently being
tested to a log file, if a path is provided
(2) if instructed, it prints the time remaining
in the exhaustive test
llvm-svn: 154205
Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more.
llvm-svn: 154160
either @dsym_test or @dwarf_test to be executed during the testsuite run. There are still lots of
Test*.py files which have not been decorated with the new decorator.
An example:
# From TestMyFirstWatchpoint.py ->
class HelloWatchpointTestCase(TestBase):
mydir = os.path.join("functionalities", "watchpoint", "hello_watchpoint")
@dsym_test
def test_hello_watchpoint_with_dsym_using_watchpoint_set(self):
"""Test a simple sequence of watchpoint creation and watchpoint hit."""
self.buildDsym(dictionary=self.d)
self.setTearDownCleanup(dictionary=self.d)
self.hello_watchpoint()
@dwarf_test
def test_hello_watchpoint_with_dwarf_using_watchpoint_set(self):
"""Test a simple sequence of watchpoint creation and watchpoint hit."""
self.buildDwarf(dictionary=self.d)
self.setTearDownCleanup(dictionary=self.d)
self.hello_watchpoint()
# Invocation ->
[17:50:14] johnny:/Volumes/data/lldb/svn/ToT/test $ ./dotest.py -N dsym -v -p TestMyFirstWatchpoint.py
LLDB build dir: /Volumes/data/lldb/svn/ToT/build/Debug
LLDB-137
Path: /Volumes/data/lldb/svn/ToT
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 154133
Node Kind: directory
Schedule: normal
Last Changed Author: gclayton
Last Changed Rev: 154109
Last Changed Date: 2012-04-05 10:43:02 -0700 (Thu, 05 Apr 2012)
Session logs for test failures/errors/unexpected successes will go into directory '2012-04-05-17_50_49'
Command invoked: python ./dotest.py -N dsym -v -p TestMyFirstWatchpoint.py
compilers=['clang']
Configuration: arch=x86_64 compiler=clang
----------------------------------------------------------------------
Collected 2 tests
1: test_hello_watchpoint_with_dsym_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Test a simple sequence of watchpoint creation and watchpoint hit. ... skipped 'dsym tests'
2: test_hello_watchpoint_with_dwarf_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Test a simple sequence of watchpoint creation and watchpoint hit. ... ok
----------------------------------------------------------------------
Ran 2 tests in 1.138s
OK (skipped=1)
Session logs for test failures/errors/unexpected successes can be found in directory '2012-04-05-17_50_49'
[17:50:50] johnny:/Volumes/data/lldb/svn/ToT/test $
llvm-svn: 154154
Right now it only works on Mac OS X, but other
platforms would just need to add their own
implementation of AddLLDBToSysPathOn*().
The stress-tester has two modes:
Used with --bytes N --random, the stress-tester
generates random instructions of length N and
runs them through the disassembler. This is
suitable for architectures like Intel where it
is combinatorially infeasible to run through the
entire space of possible instructions.
Used with --bytes N and no arguments (or --start
S --stride T), the stress-tester tests the
disassembler with a monotonically increasing
sequence of instructions.
The --start and --stride arguments are intended
for use in multiprocessing environments. Give
each core an ID from 0 .. T-1, pass the ID in as
the --start, and use T as the stride, and you
can launch one copy of the stress-tester on each
core you have available.
llvm-svn: 154143
This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems.
We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example.
Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process.
Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location.
llvm-svn: 154099
They are truncated when generating the version
numbers seen in the headers, so for example
lldb-100.1 would have #define LLDB_VERSION=100
llvm-svn: 154074
correctly if the setter/getter were not present
in the debug information. The fixes are as follows:
- We not only look for the method by its full name,
but also look for automatically-generated methods
when searching for a selector in an Objective-C
interface. This is necessary to find accessors.
- Extract the getter and setter name from the
DW_TAG_APPLE_Property declaration in the DWARF
if they are present; generate them if not.
llvm-svn: 154067
Found an issue where we might still have shared pointer references to lldb_private::Thread objects where the object itself is not valid and has been removed from the Process. When a thread is removed from a process, it will call Thread::DestroyThread() which well set a boolean member variable which is exposed now via:
bool
Thread::IsValid() const;
We then check the thread validity before handing out a shared pointer.
llvm-svn: 154048
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
(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
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
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
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
<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
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
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
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
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
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
Greg Clayton