which incurs large overheads in terms of type
parsing and importing.

llvm-svn: 154885

Fixed the ability to load multiple __LINKEDIT segments at the same address for darwin shared cache entries. Now when registering the load address of a section, the DynamicLoader objects can specify if they should warn or not. This will fix the ability to load the nlist entries for shared libraries in the darwin shared caches when no on disk representation is available for a shared library.

llvm-svn: 154860

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

Added a new host function that allows us to run shell command and get the output from them along with the status and signal:

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

of LLDB.framework.

llvm-svn: 154728

checking for LLDB mutex validity are static so
that entries put in there actually persist between
calls to error_check_mutex.

llvm-svn: 154727

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

disassembler problems:

- r153766, fixing a crash disassembling vmov
- r154628, fixing relative branches
- r154459, fixing a crash disassembling vld
- r154544, fixing a crash disassembling vst

llvm-svn: 154722

The API lock was getting dropped too soon in GetVariables.  GetValueObjectForFrameVariable could run the target (to get dynamic values) and that requires the target lock.

llvm-svn: 154711

llvm-svn: 154710

Also fixed up some logging.

llvm-svn: 154709

The run all threads timeout in RunThreadPlan should respect the user timeout, not be arbitrarily 10 seconds (which was too long anyway...)
Also added some logging to RunThreadPlan and made others more regular.

llvm-svn: 154708

Added the thread ID (tid) to each packet history item and the packet history now always dumps to a lldb_private::Stream.

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

Factor out a bunch of common code in the two ThreadPlanCallFunction constructors.  Also add a sanity check - try reading the frame, and if we fail bag out.

llvm-svn: 154698

Fixed an error where lldb would hang when writing memory near the end of the addres space due to an unsigned overflow.

llvm-svn: 154697

llvm-svn: 154683

ThreadPlanCallFunction's destructor wasn't calling DoTakedown, so if the that plan got discarded we weren't doing the takedown.

llvm-svn: 154681

Added a --memory option to allow dumping the matching malloc block memory with a default format that makes sense, or that format can be overridden with the --format option.

llvm-svn: 154671

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

llvm-svn: 154650

the MC disassembler.

llvm-svn: 154649

llvm-svn: 154638

Added more complete error checking for mutexes only for "Debug" builds where we always check if a mutex is valid prior to doing stuff with it. We also track when mutexes are initialized and destroyed and keep these in sets that can very subsequent pthread_mutex_XXX API calls.

llvm-svn: 154637

llvm-svn: 154636

Fix some test suite errors.  TestForwardDecl.py errors were due to bad Makefile.rules, while TestHiddenIvars.py errors due to features only available in modern objc runtime.

llvm-svn: 154635

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

Expose GetAddressClass() from both the SBAddress and SBInstruction so clients can tell the difference between ARM/Thumb opcodes when disassembling ARM.

llvm-svn: 154633

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

llvm-svn: 154615

Fixed an issue that happens in LLDB versions after SBFrame switched to using a lldb::ExecutionContextRefSP where we might segfault due to using a shared pointer with NULL in it. The SBFrame object should always have a valid lldb::ExecutionContextRefSP in it. The SBFrame::Clear() method was doing the wrong thing and is now fixed.

llvm-svn: 154614

Also fixed the ProcessLinux, ProcessPOSIX and ProcessFreeBSD to have the correct UpdateThreadList() prototype.

llvm-svn: 154603

(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

llvm-svn: 154600

is non-NULL before asking for its name.

llvm-svn: 154593

rdar://problem/11031264

llvm-svn: 154573

Objective-C class doesn't have a definition but
Clang tries to read through its protocols anyway.

llvm-svn: 154538

llvm-svn: 154535

Cleaned up the code and we now also dump the dynamic object for the malloc block. Using this on the lldb/test/lang/objc/foundation test we can see this in action:

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