maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Symbol/FuncUnwinders.cpp

266 lines
9.4 KiB
C++
Raw Normal View History

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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
//===-- FuncUnwinders.cpp ----------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Put plug-ins into the correct directories as they were incorrectly located in a Utility directory. llvm-svn: 130135
2011-04-26 02:36:36 +08:00
#include "lldb/Core/AddressRange.h"
#include "lldb/Core/Address.h"
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
#include "lldb/Symbol/FuncUnwinders.h"
Put plug-ins into the correct directories as they were incorrectly located in a Utility directory. llvm-svn: 130135
2011-04-26 02:36:36 +08:00
#include "lldb/Symbol/DWARFCallFrameInfo.h"
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
#include "lldb/Symbol/CompactUnwindInfo.h"
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/UnwindPlan.h"
#include "lldb/Symbol/UnwindTable.h"
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. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
#include "lldb/Target/ABI.h"
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. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
#include "lldb/Target/ExecutionContext.h"
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. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
#include "lldb/Target/Process.h"
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
#include "lldb/Target/Thread.h"
#include "lldb/Target/Target.h"
Renamed UnwindAssemblyProfiler to UnwindAssembly along with its source files. llvm-svn: 130156
2011-04-26 05:14:26 +08:00
#include "lldb/Target/UnwindAssembly.h"
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
using namespace lldb;
using namespace lldb_private;
Back out r221229 -- instead of trying to identify the end of the unwind, let's let lldb try the arch default unwind every time but not destructively -- it doesn't permanently replace the main unwind method for that function from now on. This fix is for <rdar://problem/18683658>. I tested it against Ryan Brown's go program test case and also a collection of core files of tricky unwind scenarios <rdar://problem/15664282> <rdar://problem/15835846> <rdar://problem/15982682> <rdar://problem/16099440> <rdar://problem/17364005> <rdar://problem/18556719> that I've fixed over the last 6-9 months. llvm-svn: 221238
2014-11-04 13:28:40 +08:00
FuncUnwinders::FuncUnwinders (UnwindTable& unwind_table, AddressRange range) :
m_unwind_table (unwind_table),
m_range (range),
On x86 & x86_64, try to use eh_frame for frame 0. We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not. But for x86 & x86_64 compiler generated code: 1. clang & GCC describes all prologue instructions in eh_frame; 2. mid-function stack pointer altering instructions can be easily detected. So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table. This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them. Change by Tong Shen. llvm-svn: 216406
2014-08-26 04:29:09 +08:00
m_mutex (Mutex::eMutexTypeRecursive),
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
m_unwind_plan_call_site_sp (),
m_unwind_plan_non_call_site_sp (),
m_unwind_plan_fast_sp (),
m_unwind_plan_arch_default_sp (),
Fixed issues with the unwinding code where the collection of FuncUnwinders was being searched and sorted using a shared pointer as the value which means the pointer value was what was being searched for. This means that anytime you did a stack backtrace, the collection of FuncUnwinders doubled and then the array or shared pointer got sorted (by pointer value), so you had an ever increasing collection of shared pointer where a match was never found. This means we had a ton of duplicates in this table and would cause issues after one had been debugging for a long time. llvm-svn: 123045
2011-01-08 08:05:12 +08:00
m_tried_unwind_at_call_site (false),
m_tried_unwind_at_non_call_site (false),
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
m_tried_unwind_fast (false),
m_tried_unwind_arch_default (false),
Have the FuncUnwinder object request & provide an architecture-defined UnwindPlan for unwinding from the first instruction of an otherwise unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()). Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the case of a frame 0 at address 0x0 which indicates that we jumped through a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to find the caller frame. These changes make it so lldb can identify the calling frame correctly in code like int main () { void (*f)(void) = 0; f(); } llvm-svn: 139760
2011-09-15 08:44:34 +08:00
m_tried_unwind_arch_default_at_func_entry (false),
Back out r221229 -- instead of trying to identify the end of the unwind, let's let lldb try the arch default unwind every time but not destructively -- it doesn't permanently replace the main unwind method for that function from now on. This fix is for <rdar://problem/18683658>. I tested it against Ryan Brown's go program test case and also a collection of core files of tricky unwind scenarios <rdar://problem/15664282> <rdar://problem/15835846> <rdar://problem/15982682> <rdar://problem/16099440> <rdar://problem/17364005> <rdar://problem/18556719> that I've fixed over the last 6-9 months. llvm-svn: 221238
2014-11-04 13:28:40 +08:00
m_first_non_prologue_insn ()
Fixed issues with the unwinding code where the collection of FuncUnwinders was being searched and sorted using a shared pointer as the value which means the pointer value was what was being searched for. This means that anytime you did a stack backtrace, the collection of FuncUnwinders doubled and then the array or shared pointer got sorted (by pointer value), so you had an ever increasing collection of shared pointer where a match was never found. This means we had a ton of duplicates in this table and would cause issues after one had been debugging for a long time. llvm-svn: 123045
2011-01-08 08:05:12 +08:00
{
}
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
Back out r221229 -- instead of trying to identify the end of the unwind, let's let lldb try the arch default unwind every time but not destructively -- it doesn't permanently replace the main unwind method for that function from now on. This fix is for <rdar://problem/18683658>. I tested it against Ryan Brown's go program test case and also a collection of core files of tricky unwind scenarios <rdar://problem/15664282> <rdar://problem/15835846> <rdar://problem/15982682> <rdar://problem/16099440> <rdar://problem/17364005> <rdar://problem/18556719> that I've fixed over the last 6-9 months. llvm-svn: 221238
2014-11-04 13:28:40 +08:00
FuncUnwinders::~FuncUnwinders ()
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
{
}
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
UnwindPlanSP
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
FuncUnwinders::GetUnwindPlanAtCallSite (Target &target, int current_offset)
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
{
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
Mutex::Locker locker (m_mutex);
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
if (m_tried_unwind_at_call_site == false && m_unwind_plan_call_site_sp.get() == nullptr)
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
{
Fixed issues with the unwinding code where the collection of FuncUnwinders was being searched and sorted using a shared pointer as the value which means the pointer value was what was being searched for. This means that anytime you did a stack backtrace, the collection of FuncUnwinders doubled and then the array or shared pointer got sorted (by pointer value), so you had an ever increasing collection of shared pointer where a match was never found. This means we had a ton of duplicates in this table and would cause issues after one had been debugging for a long time. llvm-svn: 123045
2011-01-08 08:05:12 +08:00
m_tried_unwind_at_call_site = true;
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
Fixed issues with the unwinding code where the collection of FuncUnwinders was being searched and sorted using a shared pointer as the value which means the pointer value was what was being searched for. This means that anytime you did a stack backtrace, the collection of FuncUnwinders doubled and then the array or shared pointer got sorted (by pointer value), so you had an ever increasing collection of shared pointer where a match was never found. This means we had a ton of duplicates in this table and would cause issues after one had been debugging for a long time. llvm-svn: 123045
2011-01-08 08:05:12 +08:00
// We have cases (e.g. with _sigtramp on Mac OS X) where the hand-written eh_frame unwind info for a
// function does not cover the entire range of the function and so the FDE only lists a subset of the
// address range. If we try to look up the unwind info by the starting address of the function
// (i.e. m_range.GetBaseAddress()) we may not find the eh_frame FDE. We need to use the actual byte offset
// into the function when looking it up.
if (m_range.GetBaseAddress().IsValid())
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
{
Fixed issues with the unwinding code where the collection of FuncUnwinders was being searched and sorted using a shared pointer as the value which means the pointer value was what was being searched for. This means that anytime you did a stack backtrace, the collection of FuncUnwinders doubled and then the array or shared pointer got sorted (by pointer value), so you had an ever increasing collection of shared pointer where a match was never found. This means we had a ton of duplicates in this table and would cause issues after one had been debugging for a long time. llvm-svn: 123045
2011-01-08 08:05:12 +08:00
Address current_pc (m_range.GetBaseAddress ());
if (current_offset != -1)
current_pc.SetOffset (current_pc.GetOffset() + current_offset);
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
CompactUnwindInfo *compact_unwind = m_unwind_table.GetCompactUnwindInfo();
if (compact_unwind)
Fixed issues with the unwinding code where the collection of FuncUnwinders was being searched and sorted using a shared pointer as the value which means the pointer value was what was being searched for. This means that anytime you did a stack backtrace, the collection of FuncUnwinders doubled and then the array or shared pointer got sorted (by pointer value), so you had an ever increasing collection of shared pointer where a match was never found. This means we had a ton of duplicates in this table and would cause issues after one had been debugging for a long time. llvm-svn: 123045
2011-01-08 08:05:12 +08:00
{
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. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
m_unwind_plan_call_site_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
if (!compact_unwind->GetUnwindPlan (target, current_pc, *m_unwind_plan_call_site_sp))
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
m_unwind_plan_call_site_sp.reset();
Fixed issues with the unwinding code where the collection of FuncUnwinders was being searched and sorted using a shared pointer as the value which means the pointer value was what was being searched for. This means that anytime you did a stack backtrace, the collection of FuncUnwinders doubled and then the array or shared pointer got sorted (by pointer value), so you had an ever increasing collection of shared pointer where a match was never found. This means we had a ton of duplicates in this table and would cause issues after one had been debugging for a long time. llvm-svn: 123045
2011-01-08 08:05:12 +08:00
}
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
if (m_unwind_plan_call_site_sp.get() == nullptr)
{
DWARFCallFrameInfo *eh_frame = m_unwind_table.GetEHFrameInfo();
if (eh_frame)
{
m_unwind_plan_call_site_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
if (!eh_frame->GetUnwindPlan (current_pc, *m_unwind_plan_call_site_sp))
m_unwind_plan_call_site_sp.reset();
}
}
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
}
}
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
return m_unwind_plan_call_site_sp;
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
}
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
UnwindPlanSP
On x86 & x86_64, try to use eh_frame for frame 0. We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not. But for x86 & x86_64 compiler generated code: 1. clang & GCC describes all prologue instructions in eh_frame; 2. mid-function stack pointer altering instructions can be easily detected. So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table. This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them. Change by Tong Shen. llvm-svn: 216406
2014-08-26 04:29:09 +08:00
FuncUnwinders::GetUnwindPlanAtNonCallSite (Target& target, Thread& thread, int current_offset)
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
{
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
Mutex::Locker locker (m_mutex);
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
if (m_tried_unwind_at_non_call_site == false && m_unwind_plan_non_call_site_sp.get() == nullptr)
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). llvm-svn: 117256
2010-10-25 19:12:07 +08:00
{
Instead of having an UnwindTable own a single assembly profiler, and sharing it with all of its FuncUnwinders, have each FuncUnwinder create an AssemblyProfiler on demand as needed. I was worried that the cost of creating the llvm disassemblers would be high for this approach but it's not supposed to be an expensive operation, and it means we don't need to add locks around this section of code. <rdar://problem/16992332> llvm-svn: 209493
2014-05-23 09:48:10 +08:00
UnwindAssemblySP assembly_profiler_sp (GetUnwindAssemblyProfiler());
if (assembly_profiler_sp)
Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to use the architectural- default-at-first-instruction UnwindPlan if we're at the beginning of a function and the ABI can provide us with an UnwindPlan to get out of there before falling back to the generic architectural default UnwindPlan (which usually assumes that the stack has already been set up.) Update the FuncUnwinders methods to gracefully handle the case where an assembly profiler may not be available. Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was returning the wrong UnwindPlan to its caller. llvm-svn: 191262
2013-09-24 10:42:54 +08:00
{
On x86 & x86_64, try to use eh_frame for frame 0. We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not. But for x86 & x86_64 compiler generated code: 1. clang & GCC describes all prologue instructions in eh_frame; 2. mid-function stack pointer altering instructions can be easily detected. So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table. This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them. Change by Tong Shen. llvm-svn: 216406
2014-08-26 04:29:09 +08:00
if (target.GetArchitecture().GetCore() == ArchSpec::eCore_x86_32_i386
Have augment_unwind_plan_from_call_site update the UnwindPlan name/from-compiler settings to indicate that it was augmented by assembly profiling. llvm-svn: 216412
2014-08-26 06:16:23 +08:00
|| target.GetArchitecture().GetCore() == ArchSpec::eCore_x86_64_x86_64
|| target.GetArchitecture().GetCore() == ArchSpec::eCore_x86_64_x86_64h)
On x86 & x86_64, try to use eh_frame for frame 0. We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not. But for x86 & x86_64 compiler generated code: 1. clang & GCC describes all prologue instructions in eh_frame; 2. mid-function stack pointer altering instructions can be easily detected. So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table. This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them. Change by Tong Shen. llvm-svn: 216406
2014-08-26 04:29:09 +08:00
{
// For 0th frame on i386 & x86_64, we fetch eh_frame and try using assembly profiler
// to augment it into asynchronous unwind table.
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
DWARFCallFrameInfo *eh_frame = m_unwind_table.GetEHFrameInfo();
if (eh_frame)
Back out r221229 -- instead of trying to identify the end of the unwind, let's let lldb try the arch default unwind every time but not destructively -- it doesn't permanently replace the main unwind method for that function from now on. This fix is for <rdar://problem/18683658>. I tested it against Ryan Brown's go program test case and also a collection of core files of tricky unwind scenarios <rdar://problem/15664282> <rdar://problem/15835846> <rdar://problem/15982682> <rdar://problem/16099440> <rdar://problem/17364005> <rdar://problem/18556719> that I've fixed over the last 6-9 months. llvm-svn: 221238
2014-11-04 13:28:40 +08:00
{
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
UnwindPlanSP unwind_plan (new UnwindPlan (lldb::eRegisterKindGeneric));
if (m_range.GetBaseAddress().IsValid())
Back out r221229 -- instead of trying to identify the end of the unwind, let's let lldb try the arch default unwind every time but not destructively -- it doesn't permanently replace the main unwind method for that function from now on. This fix is for <rdar://problem/18683658>. I tested it against Ryan Brown's go program test case and also a collection of core files of tricky unwind scenarios <rdar://problem/15664282> <rdar://problem/15835846> <rdar://problem/15982682> <rdar://problem/16099440> <rdar://problem/17364005> <rdar://problem/18556719> that I've fixed over the last 6-9 months. llvm-svn: 221238
2014-11-04 13:28:40 +08:00
{
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
Address current_pc (m_range.GetBaseAddress ());
if (current_offset != -1)
current_pc.SetOffset (current_pc.GetOffset() + current_offset);
if (eh_frame->GetUnwindPlan (current_pc, *unwind_plan))
{
if (assembly_profiler_sp->AugmentUnwindPlanFromCallSite (m_range, thread, *unwind_plan))
{
m_unwind_plan_non_call_site_sp = unwind_plan;
return m_unwind_plan_non_call_site_sp;
}
}
Copy unwind plan instead of modifying it directly, so "image show-unwind" prints different plans for asynchronous and synchronous. Change by Tong Shen. llvm-svn: 216416
2014-08-26 07:09:40 +08:00
}
}
On x86 & x86_64, try to use eh_frame for frame 0. We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not. But for x86 & x86_64 compiler generated code: 1. clang & GCC describes all prologue instructions in eh_frame; 2. mid-function stack pointer altering instructions can be easily detected. So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table. This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them. Change by Tong Shen. llvm-svn: 216406
2014-08-26 04:29:09 +08:00
}
Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to use the architectural- default-at-first-instruction UnwindPlan if we're at the beginning of a function and the ABI can provide us with an UnwindPlan to get out of there before falling back to the generic architectural default UnwindPlan (which usually assumes that the stack has already been set up.) Update the FuncUnwinders methods to gracefully handle the case where an assembly profiler may not be available. Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was returning the wrong UnwindPlan to its caller. llvm-svn: 191262
2013-09-24 10:42:54 +08:00
m_unwind_plan_non_call_site_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
Instead of having an UnwindTable own a single assembly profiler, and sharing it with all of its FuncUnwinders, have each FuncUnwinder create an AssemblyProfiler on demand as needed. I was worried that the cost of creating the llvm disassemblers would be high for this approach but it's not supposed to be an expensive operation, and it means we don't need to add locks around this section of code. <rdar://problem/16992332> llvm-svn: 209493
2014-05-23 09:48:10 +08:00
if (!assembly_profiler_sp->GetNonCallSiteUnwindPlanFromAssembly (m_range, thread, *m_unwind_plan_non_call_site_sp))
Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to use the architectural- default-at-first-instruction UnwindPlan if we're at the beginning of a function and the ABI can provide us with an UnwindPlan to get out of there before falling back to the generic architectural default UnwindPlan (which usually assumes that the stack has already been set up.) Update the FuncUnwinders methods to gracefully handle the case where an assembly profiler may not be available. Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was returning the wrong UnwindPlan to its caller. llvm-svn: 191262
2013-09-24 10:42:54 +08:00
m_unwind_plan_non_call_site_sp.reset();
}
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). llvm-svn: 117256
2010-10-25 19:12:07 +08:00
}
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
return m_unwind_plan_non_call_site_sp;
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
}
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
UnwindPlanSP
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
FuncUnwinders::GetUnwindPlanFastUnwind (Thread& thread)
{
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
Mutex::Locker locker (m_mutex);
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
if (m_tried_unwind_fast == false && m_unwind_plan_fast_sp.get() == nullptr)
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). llvm-svn: 117256
2010-10-25 19:12:07 +08:00
{
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
m_tried_unwind_fast = true;
Instead of having an UnwindTable own a single assembly profiler, and sharing it with all of its FuncUnwinders, have each FuncUnwinder create an AssemblyProfiler on demand as needed. I was worried that the cost of creating the llvm disassemblers would be high for this approach but it's not supposed to be an expensive operation, and it means we don't need to add locks around this section of code. <rdar://problem/16992332> llvm-svn: 209493
2014-05-23 09:48:10 +08:00
UnwindAssemblySP assembly_profiler_sp (GetUnwindAssemblyProfiler());
if (assembly_profiler_sp)
Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to use the architectural- default-at-first-instruction UnwindPlan if we're at the beginning of a function and the ABI can provide us with an UnwindPlan to get out of there before falling back to the generic architectural default UnwindPlan (which usually assumes that the stack has already been set up.) Update the FuncUnwinders methods to gracefully handle the case where an assembly profiler may not be available. Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was returning the wrong UnwindPlan to its caller. llvm-svn: 191262
2013-09-24 10:42:54 +08:00
{
m_unwind_plan_fast_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
Instead of having an UnwindTable own a single assembly profiler, and sharing it with all of its FuncUnwinders, have each FuncUnwinder create an AssemblyProfiler on demand as needed. I was worried that the cost of creating the llvm disassemblers would be high for this approach but it's not supposed to be an expensive operation, and it means we don't need to add locks around this section of code. <rdar://problem/16992332> llvm-svn: 209493
2014-05-23 09:48:10 +08:00
if (!assembly_profiler_sp->GetFastUnwindPlan (m_range, thread, *m_unwind_plan_fast_sp))
Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to use the architectural- default-at-first-instruction UnwindPlan if we're at the beginning of a function and the ABI can provide us with an UnwindPlan to get out of there before falling back to the generic architectural default UnwindPlan (which usually assumes that the stack has already been set up.) Update the FuncUnwinders methods to gracefully handle the case where an assembly profiler may not be available. Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was returning the wrong UnwindPlan to its caller. llvm-svn: 191262
2013-09-24 10:42:54 +08:00
m_unwind_plan_fast_sp.reset();
}
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). llvm-svn: 117256
2010-10-25 19:12:07 +08:00
}
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
return m_unwind_plan_fast_sp;
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
}
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
UnwindPlanSP
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
FuncUnwinders::GetUnwindPlanArchitectureDefault (Thread& thread)
{
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
Mutex::Locker locker (m_mutex);
Switch NULL to C++11 nullptr in source/Symbol and source/Utility Patch by Robert Matusewicz llvm-svn: 206713
2014-04-20 21:17:36 +08:00
if (m_tried_unwind_arch_default == false && m_unwind_plan_arch_default_sp.get() == nullptr)
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
{
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
m_tried_unwind_arch_default = true;
Fixed issues with the unwinding code where the collection of FuncUnwinders was being searched and sorted using a shared pointer as the value which means the pointer value was what was being searched for. This means that anytime you did a stack backtrace, the collection of FuncUnwinders doubled and then the array or shared pointer got sorted (by pointer value), so you had an ever increasing collection of shared pointer where a match was never found. This means we had a ton of duplicates in this table and would cause issues after one had been debugging for a long time. llvm-svn: 123045
2011-01-08 08:05:12 +08:00
Address current_pc;
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ProcessSP process_sp (thread.CalculateProcess());
if (process_sp)
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ABI *abi = process_sp->GetABI().get();
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. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
if (abi)
{
m_unwind_plan_arch_default_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
if (m_unwind_plan_arch_default_sp)
abi->CreateDefaultUnwindPlan(*m_unwind_plan_arch_default_sp);
}
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
}
}
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
return m_unwind_plan_arch_default_sp;
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
}
Have the FuncUnwinder object request & provide an architecture-defined UnwindPlan for unwinding from the first instruction of an otherwise unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()). Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the case of a frame 0 at address 0x0 which indicates that we jumped through a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to find the caller frame. These changes make it so lldb can identify the calling frame correctly in code like int main () { void (*f)(void) = 0; f(); } llvm-svn: 139760
2011-09-15 08:44:34 +08:00
UnwindPlanSP
FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry (Thread& thread)
{
Mutex::Locker locker (m_mutex);
Back out r221229 -- instead of trying to identify the end of the unwind, let's let lldb try the arch default unwind every time but not destructively -- it doesn't permanently replace the main unwind method for that function from now on. This fix is for <rdar://problem/18683658>. I tested it against Ryan Brown's go program test case and also a collection of core files of tricky unwind scenarios <rdar://problem/15664282> <rdar://problem/15835846> <rdar://problem/15982682> <rdar://problem/16099440> <rdar://problem/17364005> <rdar://problem/18556719> that I've fixed over the last 6-9 months. llvm-svn: 221238
2014-11-04 13:28:40 +08:00
if (m_tried_unwind_arch_default_at_func_entry == false
&& m_unwind_plan_arch_default_at_func_entry_sp.get() == nullptr)
Have the FuncUnwinder object request & provide an architecture-defined UnwindPlan for unwinding from the first instruction of an otherwise unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()). Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the case of a frame 0 at address 0x0 which indicates that we jumped through a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to find the caller frame. These changes make it so lldb can identify the calling frame correctly in code like int main () { void (*f)(void) = 0; f(); } llvm-svn: 139760
2011-09-15 08:44:34 +08:00
{
m_tried_unwind_arch_default_at_func_entry = true;
Address current_pc;
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ProcessSP process_sp (thread.CalculateProcess());
if (process_sp)
Have the FuncUnwinder object request & provide an architecture-defined UnwindPlan for unwinding from the first instruction of an otherwise unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()). Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the case of a frame 0 at address 0x0 which indicates that we jumped through a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to find the caller frame. These changes make it so lldb can identify the calling frame correctly in code like int main () { void (*f)(void) = 0; f(); } llvm-svn: 139760
2011-09-15 08:44:34 +08:00
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ABI *abi = process_sp->GetABI().get();
Have the FuncUnwinder object request & provide an architecture-defined UnwindPlan for unwinding from the first instruction of an otherwise unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()). Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the case of a frame 0 at address 0x0 which indicates that we jumped through a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to find the caller frame. These changes make it so lldb can identify the calling frame correctly in code like int main () { void (*f)(void) = 0; f(); } llvm-svn: 139760
2011-09-15 08:44:34 +08:00
if (abi)
{
m_unwind_plan_arch_default_at_func_entry_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
if (m_unwind_plan_arch_default_at_func_entry_sp)
abi->CreateFunctionEntryUnwindPlan(*m_unwind_plan_arch_default_at_func_entry_sp);
}
}
}
Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to use the architectural- default-at-first-instruction UnwindPlan if we're at the beginning of a function and the ABI can provide us with an UnwindPlan to get out of there before falling back to the generic architectural default UnwindPlan (which usually assumes that the stack has already been set up.) Update the FuncUnwinders methods to gracefully handle the case where an assembly profiler may not be available. Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was returning the wrong UnwindPlan to its caller. llvm-svn: 191262
2013-09-24 10:42:54 +08:00
return m_unwind_plan_arch_default_at_func_entry_sp;
Have the FuncUnwinder object request & provide an architecture-defined UnwindPlan for unwinding from the first instruction of an otherwise unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()). Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the case of a frame 0 at address 0x0 which indicates that we jumped through a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to find the caller frame. These changes make it so lldb can identify the calling frame correctly in code like int main () { void (*f)(void) = 0; f(); } llvm-svn: 139760
2011-09-15 08:44:34 +08:00
}
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
Address&
FuncUnwinders::GetFirstNonPrologueInsn (Target& target)
{
if (m_first_non_prologue_insn.IsValid())
return m_first_non_prologue_insn;
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. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
ExecutionContext exe_ctx (target.shared_from_this(), false);
Instead of having an UnwindTable own a single assembly profiler, and sharing it with all of its FuncUnwinders, have each FuncUnwinder create an AssemblyProfiler on demand as needed. I was worried that the cost of creating the llvm disassemblers would be high for this approach but it's not supposed to be an expensive operation, and it means we don't need to add locks around this section of code. <rdar://problem/16992332> llvm-svn: 209493
2014-05-23 09:48:10 +08:00
UnwindAssemblySP assembly_profiler_sp (GetUnwindAssemblyProfiler());
if (assembly_profiler_sp)
assembly_profiler_sp->FirstNonPrologueInsn (m_range, exe_ctx, m_first_non_prologue_insn);
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. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
return m_first_non_prologue_insn;
}
const Address&
FuncUnwinders::GetFunctionStartAddress () const
{
return m_range.GetBaseAddress();
}
Instead of having an UnwindTable own a single assembly profiler, and sharing it with all of its FuncUnwinders, have each FuncUnwinder create an AssemblyProfiler on demand as needed. I was worried that the cost of creating the llvm disassemblers would be high for this approach but it's not supposed to be an expensive operation, and it means we don't need to add locks around this section of code. <rdar://problem/16992332> llvm-svn: 209493
2014-05-23 09:48:10 +08:00
lldb::UnwindAssemblySP
FuncUnwinders::GetUnwindAssemblyProfiler ()
{
UnwindAssemblySP assembly_profiler_sp;
ArchSpec arch;
if (m_unwind_table.GetArchitecture (arch))
{
assembly_profiler_sp = UnwindAssembly::FindPlugin (arch);
}
return assembly_profiler_sp;
}
Read the LSDA and Personality Routine function address out of the eh_frame data. These two pieces of information are used in the process of exception handler unwinding on SysV ABI systems. This patch reads the data from the eh_frame section (DWARFCallFrameInfo.cpp), allows for it to be saved & read out of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well as printing the information in the UnwindPlan::Dump method - and adds methods to the FuncUnwinders object so that higher levels can query if a given function has an LSDA / personality routine defined. It's only lightly tested, but seems to be working correctly as long as your have this information in eh_frame. Does not address getting this information from compact unwind yet on Darwin systems. <rdar://problem/18742797> llvm-svn: 222214
2014-11-18 10:27:42 +08:00
Address
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
FuncUnwinders::GetLSDAAddress (Target &target)
Read the LSDA and Personality Routine function address out of the eh_frame data. These two pieces of information are used in the process of exception handler unwinding on SysV ABI systems. This patch reads the data from the eh_frame section (DWARFCallFrameInfo.cpp), allows for it to be saved & read out of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well as printing the information in the UnwindPlan::Dump method - and adds methods to the FuncUnwinders object so that higher levels can query if a given function has an LSDA / personality routine defined. It's only lightly tested, but seems to be working correctly as long as your have this information in eh_frame. Does not address getting this information from compact unwind yet on Darwin systems. <rdar://problem/18742797> llvm-svn: 222214
2014-11-18 10:27:42 +08:00
{
Address lsda_addr;
Fix up the code in the FuncUnwinders class that retrieves the personality routine addr and the LSDA addr. Don't bother checking with the "non-call site" unwind plan - this kind of information is only going to come from the call site unwind plan. llvm-svn: 222226
2014-11-18 13:57:42 +08:00
Mutex::Locker locker (m_mutex);
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
GetUnwindPlanAtCallSite (target, -1);
Fix up the code in the FuncUnwinders class that retrieves the personality routine addr and the LSDA addr. Don't bother checking with the "non-call site" unwind plan - this kind of information is only going to come from the call site unwind plan. llvm-svn: 222226
2014-11-18 13:57:42 +08:00
if (m_unwind_plan_call_site_sp && m_unwind_plan_call_site_sp->GetLSDAAddress().IsValid())
Read the LSDA and Personality Routine function address out of the eh_frame data. These two pieces of information are used in the process of exception handler unwinding on SysV ABI systems. This patch reads the data from the eh_frame section (DWARFCallFrameInfo.cpp), allows for it to be saved & read out of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well as printing the information in the UnwindPlan::Dump method - and adds methods to the FuncUnwinders object so that higher levels can query if a given function has an LSDA / personality routine defined. It's only lightly tested, but seems to be working correctly as long as your have this information in eh_frame. Does not address getting this information from compact unwind yet on Darwin systems. <rdar://problem/18742797> llvm-svn: 222214
2014-11-18 10:27:42 +08:00
{
Fix up the code in the FuncUnwinders class that retrieves the personality routine addr and the LSDA addr. Don't bother checking with the "non-call site" unwind plan - this kind of information is only going to come from the call site unwind plan. llvm-svn: 222226
2014-11-18 13:57:42 +08:00
lsda_addr = m_unwind_plan_call_site_sp->GetLSDAAddress().IsValid();
Read the LSDA and Personality Routine function address out of the eh_frame data. These two pieces of information are used in the process of exception handler unwinding on SysV ABI systems. This patch reads the data from the eh_frame section (DWARFCallFrameInfo.cpp), allows for it to be saved & read out of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well as printing the information in the UnwindPlan::Dump method - and adds methods to the FuncUnwinders object so that higher levels can query if a given function has an LSDA / personality routine defined. It's only lightly tested, but seems to be working correctly as long as your have this information in eh_frame. Does not address getting this information from compact unwind yet on Darwin systems. <rdar://problem/18742797> llvm-svn: 222214
2014-11-18 10:27:42 +08:00
}
return lsda_addr;
}
Address
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
FuncUnwinders::GetPersonalityRoutinePtrAddress (Target &target)
Read the LSDA and Personality Routine function address out of the eh_frame data. These two pieces of information are used in the process of exception handler unwinding on SysV ABI systems. This patch reads the data from the eh_frame section (DWARFCallFrameInfo.cpp), allows for it to be saved & read out of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well as printing the information in the UnwindPlan::Dump method - and adds methods to the FuncUnwinders object so that higher levels can query if a given function has an LSDA / personality routine defined. It's only lightly tested, but seems to be working correctly as long as your have this information in eh_frame. Does not address getting this information from compact unwind yet on Darwin systems. <rdar://problem/18742797> llvm-svn: 222214
2014-11-18 10:27:42 +08:00
{
Address personality_addr;
Fix up the code in the FuncUnwinders class that retrieves the personality routine addr and the LSDA addr. Don't bother checking with the "non-call site" unwind plan - this kind of information is only going to come from the call site unwind plan. llvm-svn: 222226
2014-11-18 13:57:42 +08:00
Mutex::Locker locker (m_mutex);
The lldb unwinder can now use the unwind information from the compact-unwind section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
2014-12-08 11:09:00 +08:00
GetUnwindPlanAtCallSite (target, -1);
Fix up the code in the FuncUnwinders class that retrieves the personality routine addr and the LSDA addr. Don't bother checking with the "non-call site" unwind plan - this kind of information is only going to come from the call site unwind plan. llvm-svn: 222226
2014-11-18 13:57:42 +08:00
if (m_unwind_plan_call_site_sp && m_unwind_plan_call_site_sp->GetPersonalityFunctionPtr().IsValid())
Read the LSDA and Personality Routine function address out of the eh_frame data. These two pieces of information are used in the process of exception handler unwinding on SysV ABI systems. This patch reads the data from the eh_frame section (DWARFCallFrameInfo.cpp), allows for it to be saved & read out of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well as printing the information in the UnwindPlan::Dump method - and adds methods to the FuncUnwinders object so that higher levels can query if a given function has an LSDA / personality routine defined. It's only lightly tested, but seems to be working correctly as long as your have this information in eh_frame. Does not address getting this information from compact unwind yet on Darwin systems. <rdar://problem/18742797> llvm-svn: 222214
2014-11-18 10:27:42 +08:00
{
Fix up the code in the FuncUnwinders class that retrieves the personality routine addr and the LSDA addr. Don't bother checking with the "non-call site" unwind plan - this kind of information is only going to come from the call site unwind plan. llvm-svn: 222226
2014-11-18 13:57:42 +08:00
personality_addr = m_unwind_plan_call_site_sp->GetPersonalityFunctionPtr().IsValid();
Read the LSDA and Personality Routine function address out of the eh_frame data. These two pieces of information are used in the process of exception handler unwinding on SysV ABI systems. This patch reads the data from the eh_frame section (DWARFCallFrameInfo.cpp), allows for it to be saved & read out of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well as printing the information in the UnwindPlan::Dump method - and adds methods to the FuncUnwinders object so that higher levels can query if a given function has an LSDA / personality routine defined. It's only lightly tested, but seems to be working correctly as long as your have this information in eh_frame. Does not address getting this information from compact unwind yet on Darwin systems. <rdar://problem/18742797> llvm-svn: 222214
2014-11-18 10:27:42 +08:00
}
return personality_addr;
}