History log of /external/lldb/include/lldb/Symbol/UnwindPlan.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
102b2c2681c9a830afe25bfea35557421905e42c 19-Apr-2013 Greg Clayton <gclayton@apple.com> After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
37816a3429a075e19b74f64fd642d5a5d7ec6f2f 26-Oct-2012 Jason Molenda <jmolenda@apple.com> Add a new capability to RegisterContextLLDB: To recognize when the
Full UnwindPlan is trying to do an impossible unwind; in that case
invalidate the Full UnwindPlan and replace it with the architecture
default unwind plan.

This is a scenario that happens occasionally with arm unwinds in
particular; the instruction analysis based full unwindplan can
mis-parse the functions and the stack walk stops prematurely. Now
we can do a simpleminded frame-chain walk to find the caller frame
and continue the unwind. It's not ideal but given the complicated
nature of analyzing the arm functions, and the lack of eh_frame
information on iOS, it is a distinct improvement and fixes some
long-standing problems with the unwinder on that platform.

This is fixing <rdar://problem/12091421>. I may re-use this
invalidate feature in the future if I can identify other cases where
the full unwindplan's unwind information is clearly incorrect.

This checkin also includes some cleanup for the volatile register
definition in the arm ABI plugin for <rdar://problem/10652166>
although work remains to be done for that bug.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166757 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
f68a2050b1a85de977829ffb7e327a991fddad33 18-Aug-2012 Jason Molenda <jmolenda@apple.com> Some eh_frame unwind instructions will define a return address register;
when you want to find the caller's saved pc, you look up the return address
register and use that. On arm, for instance, this would be the contents of
the link register (lr).

If the eh_frame CIE defines an RA, record that fact in the UnwindPlan.

When we're finding a saved register, if it's the pc, lok for the location
of the return address register instead.

<rdar://problem/12062310>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162167 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
090d19b89ab067916de9405aa5579c947e7ce41b 18-Jul-2012 Greg Clayton <gclayton@apple.com> Cleaned up incorrect STL std::map comparison code and use the operator == on std::map objects instead of manually implementing the comparisons. Also modified the UnwindPlan::AppendRow() function to take a "const RowSP &" object so we don't have to copy shared pointers when calling this function.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160448 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
a092d901bec2beaed29603acad318d8d93da3f4a 17-Jul-2012 Jason Molenda <jmolenda@apple.com> Change UnwindAssemblyInstEmulation::GetNonCallSiteUnwindPlanFromAssembly so it records
the state of the unwind instructions once the prologue has finished. If it hits an
early return epilogue in the middle of the function, re-instate the prologue after that
epilogue has completed so that we can still unwind for cases where the flow of control
goes past that early-return. <rdar://problem/11775059>

Move the UnwindPlan operator== definition into the .cpp file, expand the definition a bit.

Add some casts to a SBCommandInterpreter::HandleCompletion() log statement so it builds without
warning on 64- and 32-bit systems.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160337 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
68fa4ec4361d1ea5a78a8a7eba2b8015e3dd68f7 14-Jul-2012 Jason Molenda <jmolenda@apple.com> Switch nearly all of the use of the UnwindPlan::Row's to go through
a shared pointer to ease some memory management issues with a patch
I'm working on.

The main complication with using SPs for these objects is that most
methods that build up an UnwindPlan will construct a Row to a given
instruction point in a function, then add additional regsaves in
the next instruction point to that row and push it again. A little
care is needed to not mutate the previous instruction point's Row
once these are switched to being held behing shared pointers.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160214 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
5c3861df62fde02d610a5ed92927a2d89333358b 02-Sep-2011 Greg Clayton <gclayton@apple.com> Added the ability for DWARF locations to use the ABI plug-ins to resolve
register names when dumping variable locations and location lists. Also did
some cleanup where "int" types were being used for "lldb::RegisterKind"
values.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138988 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
75906e4ec98af3717e415727a8d663a4e246bb4f 11-May-2011 Greg Clayton <gclayton@apple.com> Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their
respective ABI plugins as they were plug-ins that supplied ABI specfic info.

Also hookep up the UnwindAssemblyInstEmulation so that it can generate the
unwind plans for ARM.

Changed the way ABI plug-ins are handed out when you get an instance from
the plug-in manager. They used to return pointers that would be mananged
individually by each client that requested them, but now they are handed out
as shared pointers since there is no state in the ABI objects, they can be
shared.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131193 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
c07d451bb046e47215bd73fda0235362cc6b1a47 27-Apr-2011 Greg Clayton <gclayton@apple.com> Got the EmulateInstruction CFI code a lot closer to producing CFI data.

Switch the EmulateInstruction to use the standard RegisterInfo structure
that is defined in the lldb private types intead of passing the reg kind and
reg num everywhere. EmulateInstruction subclasses also need to provide
RegisterInfo structs given a reg kind and reg num. This eliminates the need
for the GetRegisterName() virtual function and allows more complete information
to be passed around in the read/write register callbacks. Subclasses should
always provide RegiterInfo structs with the generic register info filled in as
well as at least one kind of register number in the RegisterInfo.kinds[] array.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130256 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
a8d4241dcd129f289710c909491e0e80e7e3d732 09-Feb-2011 Greg Clayton <gclayton@apple.com> Added the DWARF unique type map such that we only create a type once in the
module's AST context. Prior to this fix, with gcc binaries, we end up with
a full class definition for any used classes in each compile unit due to the
one definition rule. This would result in us making N copies of class T, where
N is the number of compile units that use class T, in the module AST. When
an expression would then try and use any types that were duplicated, it would
quickly confuse clang and make expression evaluation fail due to all of the
duplicate types that got copied over. This is now fixed by making a map of
types in the DWARF that maps type names to a collection of types + declaration
(file + line number) + DIE. Then later when we find a type we look in this
module map and find any already cached types that we can just use.

8935777



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125207 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
5382281cce4d2de419628a39b1284eca38b12d66 08-Jan-2011 Greg Clayton <gclayton@apple.com> Made FuncUnwinders threadsafe.

Other small cleanups as well.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123088 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
8e69de4b9c55ec2eaebc62e4d987c2f0618ac431 20-Nov-2010 Jason Molenda <jmolenda@apple.com> Change the DWARFExpression::Evaluate methods to take an optional
RegisterContext* - normally this is retrieved from the ExecutionContext's
StackFrame but when we need to evaluate an expression while creating
the stack frame list this can be a little tricky.

Add DW_OP_deref_size, needed for the _sigtramp FDE expression.

Add support for processing DWARF expressions in RegisterContextLLDB.

Update callers to DWARFExpression::Evaluate.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@119885 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
a6b71de68536fd9c9917f59e42f1d8e39b06f8fc 04-Nov-2010 Jason Molenda <jmolenda@apple.com> Built the native unwinder with all the warnings c++-4.2 could muster;
fixed them. Added DISALLOW_COPY_AND_ASSIGN to classes that should
not be bitwise copied. Added default initializers for member
variables that weren't being initialized in the ctor. Fixed a few
shadowed local variable mistakes.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118240 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
8280cbe80c79bc206335831dd732e0f9fb69c519 25-Oct-2010 Jason Molenda <jmolenda@apple.com> Check in the native lldb unwinder.

Not yet enabled as the default unwinder but there are no known
backtrace problems with the code at this point.

Added 'log enable lldb unwind' to help diagnose backtrace problems;
this output needs a little refining but it's a good first step.

eh_frame information is currently read unconditionally - the code
is structured to allow this to be delayed until it's actually needed.
There is a performance hit when you have to parse the eh_frame
information for any largeish executable/library so it's necessary
to avoid if possible.

It's confusing having both the UnwindPlan::RegisterLocation struct
and the RegisterConextLLDB::RegisterLocation struct, I need to rename
one of them.

The writing of registers isn't done in the RegisterConextLLDB subclass
yet; neither is the running of complex DWARF expressions from eh_frame
(e.g. used for _sigtramp on Mac OS X).



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117256 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
4c273fd84b6233fba1f2ce9d34affa5c349d0911 16-Sep-2010 Benjamin Kramer <benny.kra@googlemail.com> Unbreak build, you can't take a pointer from a "register" variable. Most compilers ignore this keyword anyways.

Also remove a typedef that typedefs nothing.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114083 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
eea264007bc5fb42c8f3239726a9d28ae42e1b7b 15-Sep-2010 Greg Clayton <gclayton@apple.com> Moved the section load list up into the target so we can use the target
to symbolicate things without the need for a valid process subclass.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113895 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h
3a4ea24572fad1e22525f8efb718d49d41e30398 10-Sep-2010 Jason Molenda <jmolenda@apple.com> The first part of an lldb native stack unwinder.

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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113581 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/UnwindPlan.h