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
a method:
void RegisterContext::InvalidateIfNeeded (bool force);
Each time this function is called, when "force" is false, it will only call
the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if
the register context's stop ID doesn't match that of the process. When the
stop ID doesn't match, or "force" is true, the base class will clear its
cached registers and the RegisterContext will update its stop ID to match
that of the process. This helps make it easier to correctly flush the register
context (possibly from multiple locations depending on when and where new
registers are availabe) without inadvertently clearing the register cache
when it doesn't need to be.
Modified the ProcessGDBRemote plug-in to be much more efficient when it comes
to:
- caching the expedited registers in the stop reply packets (we were ignoring
these before and it was causing us to read at least three registers every
time we stopped that were already supplied in the stop reply packet).
- When a thread has no stop reason, don't keep asking for the thread stopped
info. Prior to this fix we would continually send a qThreadStopInfo packet
over and over when any thread stop info was requested. We now note the stop
ID that the stop info was requested for and avoid multiple requests.
Cleaned up some of the expression code to not look for ClangExpressionVariable
objects up by name since they are now shared pointers and we can just look for
the exact pointer match and avoid possible errors.
Fixed an bug in the ValueObject code that would cause children to not be
displayed.
llvm-svn: 123127
an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.
Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete
frame itself.
So now the stack frames and the register contexts should behave much better.
llvm-svn: 122976
all of the calls inlined in the header file for better performance.
Fixed the summary for C string types (array of chars (with any combo if
modifiers), and pointers to chars) work in all cases.
Fixed an issue where a forward declaration to a clang type could cause itself
to resolve itself more than once if, during the resolving of the type itself
it caused something to try and resolve itself again. We now remove the clang
type from the forward declaration map in the DWARF parser when we start to
resolve it and avoid this additional call. This should stop any duplicate
members from appearing and throwing all the alignment of structs, unions and
classes.
llvm-svn: 117437
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
