I added support for asking if the GDB remote server supports thread suffixes
for packets that should be thread specific (register read/write packets) because
the way the GDB remote protocol does it right now is to have a notion of a
current thread for register and memory reads/writes (set via the "$Hg%x" packet)
and a current thread for running ("$Hc%x"). Now we ask the remote GDB server
if it supports adding the thread ID to the register packets and we enable
that feature in LLDB if supported. This stops us from having to send a bunch
of packets that update the current thread ID to some value which is prone to
error, or extra packets.
llvm-svn: 123762
new "hexname" key for the "key:value;" duple that is part of the packet. This
allows for thread names to contain special characters such as $ # : ; + -
Debugserver now detects if the thread name contains special characters and
sends the chars in hex format if needed.
llvm-svn: 123053
Added a virtual destructor to ClangUtilityFunction with a body to it cleans
itself up.
Moved our SharingPtr into the lldb_private namespace to keep it easy to make
an exports file that exports only what is needed ("lldb::*").
llvm-svn: 114771
whether a given register number is treated as volatile
or not for a given architecture/platform.
approx 450 lines of boilerplate, 50 lines of actual code. :)
llvm-svn: 114537
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
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
We need to put this in LLDB since we need to vend this in our API
because our public API uses shared pointers to our private objects.
Removed a deprecated file: include/lldb/Host/Types.h
Added the new SharingPtr.cpp/.h files into source/Utility.
Added a shell script build phase that fixes up all headers in the
LLDB.framework.
llvm-svn: 105895
The top of the header file seems to indicate that this was
intended to be over at include/lldb/Core but we should be in line
with the .cpp file's location so it's include/lldb/Utility for now.
llvm-svn: 105753
Greg Clayton