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
the pre-flight code gets executed during setUp() after the debugger instance is available
and the post-flight code gets executed during tearDown() after the debugger instance has
done killing the inferior and deleting all the target programs.
Example:
[11:32:48] johnny:/Volumes/data/lldb/svn/ToT/test $ ./dotest.py -A x86_64 -v -c ../examples/test/.lldb-pre-post-flight functionalities/watchpoint/hello_watchpoint
config: {'pre_flight': <function pre_flight at 0x1098541b8>, 'post_flight': <function post_flight at 0x109854230>}
LLDB build dir: /Volumes/data/lldb/svn/ToT/build/Debug
LLDB-139
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: 154753
Node Kind: directory
Schedule: normal
Last Changed Author: gclayton
Last Changed Rev: 154730
Last Changed Date: 2012-04-13 18:42:46 -0700 (Fri, 13 Apr 2012)
lldb.pre_flight: def pre_flight(test):
__import__("lldb")
__import__("lldbtest")
print "\nRunning pre-flight function:"
print "for test case:", test
lldb.post_flight: def post_flight(test):
__import__("lldb")
__import__("lldbtest")
print "\nRunning post-flight function:"
print "for test case:", test
Session logs for test failures/errors/unexpected successes will go into directory '2012-04-16-11_34_08'
Command invoked: python ./dotest.py -A x86_64 -v -c ../examples/test/.lldb-pre-post-flight functionalities/watchpoint/hello_watchpoint
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. ...
Running pre-flight function:
for test case: test_hello_watchpoint_with_dsym_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Running post-flight function:
for test case: test_hello_watchpoint_with_dsym_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
ok
2: test_hello_watchpoint_with_dwarf_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Test a simple sequence of watchpoint creation and watchpoint hit. ...
Running pre-flight function:
for test case: test_hello_watchpoint_with_dwarf_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Running post-flight function:
for test case: test_hello_watchpoint_with_dwarf_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
ok
----------------------------------------------------------------------
Ran 2 tests in 1.584s
OK
llvm-svn: 154847
Error
Host::RunShellCommand (const char *command,
const char *working_dir,
int *status_ptr,
int *signo_ptr,
std::string *command_output_ptr,
uint32_t timeout_sec);
This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo.
llvm-svn: 154730
Hello everyone,
please find the attached patch for TOT and lldb-platform-work branch, which provides the following changes:
- fixed a crash in the ProcessPOSIX constructor when an executable module object is not yet created.
- added support for the multi instanciated FreeBSD platform objects (the local host and remote as example).
- enabled the remote gdb plugin on FreeBSD.
llvm-svn: 154724
Enable logging the packet history when registers fail to read due to not getting the sequence mutex if "--verbose" is enabled on the log channel for the "gdb-remote" log category.
This will help us track down some issues.
llvm-svn: 154704
For the types directory, we were running lldbtest.system() to execute the compiled program
on the test host to collect golden output in order to compare with the output of various
lldb debugger commands as performed later. This won't work for the remote platform
scenario where the architecture of the target and host platforms are different.
Modify the AbstractBase class to use lldb to launch the inferior while specifying the
output file, from which the golden output is collected and grokked. How to bootstrap and
to connect to the remote platform is still being worked at.
llvm-svn: 154699
The less locks there are, the better. I removed the thread ID mutex and now just shared the m_thread_list's mutex to make sure we don't deadlock due to lock inversion.
llvm-svn: 154652
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
Greg Clayton