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

llvm-svn: 154506

Added a new "heap.py" module that adds a new command line command that can find values on the heap and print out the dynamic type of the malloc block that contains the data. I will be modifying this a bit more to tweak the output and make the output more useful.

llvm-svn: 154504

llvm-svn: 154503

llvm-svn: 154502

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

llvm-svn: 154450

cover all possible condition codes.

llvm-svn: 154440

Added more documentation in the header file to explain how to use the results that are found by the function calls to find_pointer_in_heap().

llvm-svn: 154435

llvm-svn: 154419

not consume slots in the persistent variable
store.

llvm-svn: 154416

	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

A general stability fix where we _always_ get the thread list immediately after we get the stop packets. We had some racy conditions where thread 1 might be sending a packet and thread 2 tries to send a packet to get the thread list and it fails and ends up with an empty list. Packets use a sequence mutex to be able to ensure when you send a packet, you get the resonse. This sequence mutex is take when the process is running, and as we exit the running state and notify our process with the stop packet, we now always get the thread ID list before we do anything and before we can run into race conditions. 

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

Clear the "m_actual_stop_info_sp" in the thread during Destroy.  It might be a StopInfoThreadPlan, and that would hold onto members that need to be destroyed while the Full thread is still around.

llvm-svn: 154366