5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae |
|
29-Nov-2012 |
Daniel Malea <daniel.malea@intel.com> |
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
e773e4d5f1fdb2765f991c2126b32514622f315d |
|
10-Aug-2012 |
Jason Molenda <jmolenda@apple.com> |
Remove a little unuseful output from the UnwindPlan::Row::Dump and UnwindPlan::Dump methods. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@161696 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
f4124deeb9532044a38c0774ced872f2709347da |
|
21-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/UnwindPlan.cpp
|
7e5fa7fc1f8efd24c078e063b2c4b5e13ba5be20 |
|
20-Sep-2011 |
Jason Molenda <jmolenda@apple.com> |
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140185 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/UnwindPlan.cpp
|
a65ac250d7b1ee0e45ca10ec70a24f4a41537dbb |
|
12-Aug-2011 |
Johnny Chen <johnny.chen@apple.com> |
Fix two 'dereference of a null pointer' detected by the static analyzer. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137394 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
08d7d3ae16110aa68ed40c161eac8571aeb94cd9 |
|
06-Jan-2011 |
Greg Clayton <gclayton@apple.com> |
Fixed issues with RegisterContext classes and the subclasses. There was 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. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/UnwindPlan.cpp
|
800d11d87769e1a7083f7a5545613625396deb3e |
|
04-Nov-2010 |
Jason Molenda <jmolenda@apple.com> |
Handle the case where no eh_frame section is present. RegisterContextLLDB holds a reference to the SymbolContext in the vector of Cursors that UnwindLLDB maintains. Switch UnwindLLDB to hold a vector of shared pointers of Cursors so this reference doesn't become invalid. Correctly falling back from the "fast" UnwindPlan to the "full" UnwindPlan when additional registers need to be retrieved. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118218 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|
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/source/Symbol/UnwindPlan.cpp
|