it with llvm::sys::Program::FindProgramByName.

llvm-svn: 113709

The Unwind and RegisterContext subclasses still need
to be finished; none of this code is used by lldb at
this point (unless you call into it by hand).

The ObjectFile class now has an UnwindTable object.

The UnwindTable object has a series of FuncUnwinders
objects (Function Unwinders) -- one for each function
in that ObjectFile we've backtraced through during this
debug session.

The FuncUnwinders object has a few different UnwindPlans.
UnwindPlans are a generic way of describing how to find
the canonical address of a given function's stack frame
(the CFA idea from DWARF/eh_frame) and how to restore the
caller frame's register values, if they have been saved
by this function.

UnwindPlans are created from different sources.  One source is the
eh_frame exception handling information generated by the compiler
for unwinding an exception throw.  Another source is an assembly
language inspection class (UnwindAssemblyProfiler, uses the Plugin
architecture) which looks at the instructions in the funciton
prologue and describes the stack movements/register saves that are
done.

Two additional types of UnwindPlans that are worth noting are
the "fast" stack UnwindPlan which is useful for making a first
pass over a thread's stack, determining how many stack frames there
are and retrieving the pc and CFA values for each frame (enough
to create StackFrameIDs).  Only a minimal set of registers is
recovered during a fast stack walk.  

The final UnwindPlan is an architectural default unwind plan.
These are provided by the ArchDefaultUnwindPlan class (which uses
the plugin architecture).  When no symbol/function address range can
be found for a given pc value -- when we have no eh_frame information
and when we don't have a start address so we can't examine the assembly
language instrucitons -- we have to make a best guess about how to 
unwind.  That's when we use the architectural default UnwindPlan.
On x86_64, this would be to assume that rbp is used as a stack pointer
and we can use that to find the caller's frame pointer and pc value.
It's a last-ditch best guess about how to unwind out of a frame.

There are heuristics about when to use one UnwindPlan versues the other --
this will all happen in the still-begin-written UnwindLLDB subclass of
Unwind which runs the UnwindPlans.

llvm-svn: 113581

and the user didn't specify a particular directory, search for the file 
using the $PATH environment variable.

llvm-svn: 113575

llvm-svn: 113438

code between linux, darwin and BSD.

llvm-svn: 113263

not release it by making sure a mutex locker object is appropriately used.

llvm-svn: 112996

were not needed and fixed a merge issue.

llvm-svn: 112626

is disabled by default, and can be enabled using:

(lldb) set disable-aslr 0

llvm-svn: 112616

llvm-svn: 112614

llvm-svn: 112558

is launched with the -e option on Mac OS X.

llvm-svn: 112536

Added a way to open the current source file & line in an external editor, and you can turn this on with:

lldb -e

llvm-svn: 112502

thread name but the static map instance had already been destructed.

rdar://problem/8153284

llvm-svn: 111812

to spawn a thread for each process that is being monitored. Previously
LLDB would spawn a single thread that would wait for any child process which
isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on
linux). The old single thread used to call wait4() with a pid of -1 which 
could cause it to reap child processes that it shouldn't have.

Re-wrote the way Function blocks are handles. Previously I attempted to keep
all blocks in a single memory allocation (in a std::vector). This made the
code somewhat efficient, but hard to work with. I got rid of the old BlockList
class, and went to a straight parent with children relationship. This new 
approach will allow for partial parsing of the blocks within a function.

llvm-svn: 111706

llvm-svn: 110676

Arrange that this then gets properly set on attach, or when a "file" is set.
Add a completer for "process attach -n".

Caveats: there isn't currently a way to handle multiple processes with the same name.  That
will have to wait on a way to pass annotations along with the completion strings.

llvm-svn: 110624

ThreadCancel in Host::WillTerminate g_monitor_thread may be blocked on a call
to pthread_cond_wait (for example, line 640).  Now, by default, when a 
cancellation request is serviced g_monitor_thread will again own the mutex
guarding the condition variable it was waiting on.  This causes the call to 
SetValue in Host::WillTerminate to hit a deadlock.

The call to SetValue does not appear to be needed, so removing it solves
the issue.

Patch from Stephen Wilson.

llvm-svn: 109228

llvm-svn: 109226

defines that are in "llvm/Support/MachO.h". This should allow ObjectFileMachO
and ObjectContainerUniversalMachO to be able to be cross compiled in Linux.

Also did some cleanup on the ASTType by renaming it to ClangASTType and
renaming the header file. Moved a lot of "AST * + opaque clang type *"
functionality from lldb_private::Type over into ClangASTType.

llvm-svn: 109046

enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.

llvm-svn: 108009

llvm-svn: 107794

llvm-svn: 107692

llvm-svn: 107502

compiling lldb.  Someone else might try to improve it, though. :)

llvm-svn: 107501

be shared with linux.

Updated Xcode project.

llvm-svn: 105928

llvm-svn: 105814

llvm-svn: 105812

type and sub-type, or an ELF e_machine value. Also added a generic CPU type
to the arch spec class so we can have a single arch definition that the LLDB
core code can use. Previously a lot of places in the code were using the
mach-o definitions from a macosx header file. 

Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the
CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so 
we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs.

Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being
used in LLDB.

llvm-svn: 105806

llvm-svn: 105619