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

361 lines
12 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;
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
//------------------------------------------------
/// constructor
//------------------------------------------------
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 (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),
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_assembly_sp (),
m_unwind_plan_eh_frame_sp (),
m_unwind_plan_eh_frame_augmented_sp (),
m_unwind_plan_compact_unwind (),
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_fast_sp (),
m_unwind_plan_arch_default_sp (),
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_arch_default_at_func_entry_sp (),
m_tried_unwind_plan_assembly (false),
m_tried_unwind_plan_eh_frame (false),
m_tried_unwind_plan_eh_frame_augmented (false),
m_tried_unwind_plan_compact_unwind (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
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
//------------------------------------------------
/// destructor
//------------------------------------------------
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);
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
UnwindPlanSP unwind_plan_sp = GetEHFrameUnwindPlan (target, current_offset);
if (unwind_plan_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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
unwind_plan_sp = GetCompactUnwindUnwindPlan (target, 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
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
return unwind_plan_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
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
UnwindPlanSP
FuncUnwinders::GetCompactUnwindUnwindPlan (Target &target, int current_offset)
{
if (m_unwind_plan_compact_unwind.size() > 0)
return m_unwind_plan_compact_unwind[0]; // FIXME support multiple compact unwind plans for one func
if (m_tried_unwind_plan_compact_unwind)
return UnwindPlanSP();
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
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
Mutex::Locker lock (m_mutex);
m_tried_unwind_plan_compact_unwind = true;
if (m_range.GetBaseAddress().IsValid())
{
Address current_pc (m_range.GetBaseAddress ());
if (current_offset != -1)
current_pc.SetOffset (current_pc.GetOffset() + current_offset);
CompactUnwindInfo *compact_unwind = m_unwind_table.GetCompactUnwindInfo();
if (compact_unwind)
{
UnwindPlanSP unwind_plan_sp (new UnwindPlan (lldb::eRegisterKindGeneric));
if (compact_unwind->GetUnwindPlan (target, current_pc, *unwind_plan_sp))
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_compact_unwind.push_back (unwind_plan_sp);
return m_unwind_plan_compact_unwind[0]; // FIXME support multiple compact unwind plans for one func
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
}
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
}
}
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
return 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
}
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
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
FuncUnwinders::GetEHFrameUnwindPlan (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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
if (m_unwind_plan_eh_frame_sp.get() || m_tried_unwind_plan_eh_frame)
return m_unwind_plan_eh_frame_sp;
Mutex::Locker lock (m_mutex);
m_tried_unwind_plan_eh_frame = true;
if (m_range.GetBaseAddress().IsValid())
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
Address current_pc (m_range.GetBaseAddress ());
if (current_offset != -1)
current_pc.SetOffset (current_pc.GetOffset() + current_offset);
DWARFCallFrameInfo *eh_frame = m_unwind_table.GetEHFrameInfo();
if (eh_frame)
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_eh_frame_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
if (!eh_frame->GetUnwindPlan (current_pc, *m_unwind_plan_eh_frame_sp))
m_unwind_plan_eh_frame_sp.reset();
}
}
return m_unwind_plan_eh_frame_sp;
}
UnwindPlanSP
FuncUnwinders::GetEHFrameAugmentedUnwindPlan (Target &target, Thread &thread, int current_offset)
{
if (m_unwind_plan_eh_frame_augmented_sp.get() || m_tried_unwind_plan_eh_frame_augmented)
return m_unwind_plan_eh_frame_augmented_sp;
// Only supported on x86 architectures where we get eh_frame from the compiler that describes
// the prologue instructions perfectly, and sometimes the epilogue instructions too.
if (target.GetArchitecture().GetCore() != ArchSpec::eCore_x86_32_i386
&& target.GetArchitecture().GetCore() != ArchSpec::eCore_x86_64_x86_64
&& target.GetArchitecture().GetCore() != ArchSpec::eCore_x86_64_x86_64h)
{
m_tried_unwind_plan_eh_frame_augmented = true;
return m_unwind_plan_eh_frame_augmented_sp;
}
Mutex::Locker lock (m_mutex);
m_tried_unwind_plan_eh_frame_augmented = true;
if (m_range.GetBaseAddress().IsValid())
{
Address current_pc (m_range.GetBaseAddress ());
if (current_offset != -1)
current_pc.SetOffset (current_pc.GetOffset() + current_offset);
DWARFCallFrameInfo *eh_frame = m_unwind_table.GetEHFrameInfo();
if (eh_frame)
{
m_unwind_plan_eh_frame_augmented_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
if (!eh_frame->GetUnwindPlan (current_pc, *m_unwind_plan_eh_frame_augmented_sp))
{
m_unwind_plan_eh_frame_augmented_sp.reset();
}
else
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
// Augment the eh_frame instructions with epilogue descriptions if necessary so the
// UnwindPlan can be used at any instruction in the function.
UnwindAssemblySP assembly_profiler_sp (GetUnwindAssemblyProfiler());
if (assembly_profiler_sp)
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
if (!assembly_profiler_sp->AugmentUnwindPlanFromCallSite (m_range, thread, *m_unwind_plan_eh_frame_augmented_sp))
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_eh_frame_augmented_sp.reset();
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
}
}
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
else
{
m_unwind_plan_eh_frame_augmented_sp.reset();
}
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
}
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
}
}
return m_unwind_plan_eh_frame_augmented_sp;
}
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
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
UnwindPlanSP
FuncUnwinders::GetAssemblyUnwindPlan (Target &target, Thread &thread, int current_offset)
{
if (m_unwind_plan_assembly_sp.get() || m_tried_unwind_plan_assembly)
return m_unwind_plan_assembly_sp;
Mutex::Locker lock (m_mutex);
m_tried_unwind_plan_assembly = true;
UnwindAssemblySP assembly_profiler_sp (GetUnwindAssemblyProfiler());
if (assembly_profiler_sp)
{
m_unwind_plan_assembly_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
if (!assembly_profiler_sp->GetNonCallSiteUnwindPlanFromAssembly (m_range, thread, *m_unwind_plan_assembly_sp))
{
m_unwind_plan_assembly_sp.reset();
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
}
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
}
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
return m_unwind_plan_assembly_sp;
}
UnwindPlanSP
FuncUnwinders::GetUnwindPlanAtNonCallSite (Target& target, Thread& thread, int current_offset)
{
UnwindPlanSP non_call_site_unwindplan_sp = GetEHFrameAugmentedUnwindPlan (target, thread, current_offset);
if (non_call_site_unwindplan_sp.get() == nullptr)
{
non_call_site_unwindplan_sp = GetAssemblyUnwindPlan (target, thread, current_offset);
}
return non_call_site_unwindplan_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)
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
if (m_unwind_plan_fast_sp.get() || m_tried_unwind_fast)
return m_unwind_plan_fast_sp;
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
Mutex::Locker locker (m_mutex);
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_tried_unwind_fast = true;
UnwindAssemblySP assembly_profiler_sp (GetUnwindAssemblyProfiler());
if (assembly_profiler_sp)
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_fast_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_fast_sp.reset();
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
}
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)
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
if (m_unwind_plan_arch_default_sp.get() || m_tried_unwind_arch_default)
return m_unwind_plan_arch_default_sp;
Made FuncUnwinders threadsafe. Other small cleanups as well. llvm-svn: 123088
2011-01-09 05:19:00 +08:00
Mutex::Locker locker (m_mutex);
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_tried_unwind_arch_default = true;
Address current_pc;
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
ABI *abi = process_sp->GetABI().get();
if (abi)
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_arch_default_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
if (!abi->CreateDefaultUnwindPlan(*m_unwind_plan_arch_default_sp))
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_arch_default_sp.reset();
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
}
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)
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
if (m_unwind_plan_arch_default_at_func_entry_sp.get() || m_tried_unwind_arch_default_at_func_entry)
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
Mutex::Locker locker (m_mutex);
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_tried_unwind_arch_default_at_func_entry = true;
Address current_pc;
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
ABI *abi = process_sp->GetABI().get();
if (abi)
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_arch_default_at_func_entry_sp.reset (new UnwindPlan (lldb::eRegisterKindGeneric));
if (!abi->CreateFunctionEntryUnwindPlan(*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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
m_unwind_plan_arch_default_at_func_entry_sp.reset();
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
}
}
}
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;
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
Mutex::Locker locker (m_mutex);
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
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
UnwindPlanSP unwind_plan_sp = GetEHFrameUnwindPlan (target, -1);
if (unwind_plan_sp.get() == nullptr)
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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
unwind_plan_sp = GetCompactUnwindUnwindPlan (target, -1);
}
if (unwind_plan_sp.get() && unwind_plan_sp->GetLSDAAddress().IsValid())
{
lsda_addr = unwind_plan_sp->GetLSDAAddress();
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
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
UnwindPlanSP unwind_plan_sp = GetEHFrameUnwindPlan (target, -1);
if (unwind_plan_sp.get() == nullptr)
{
unwind_plan_sp = GetCompactUnwindUnwindPlan (target, -1);
}
if (unwind_plan_sp.get() && unwind_plan_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
{
Various unwinder work. Most of the changes are to the FuncUnwinders class -- as we've added more types of unwind information, the way this class was written was making it a mess to maintain. Instead of trying to keep one "non-call site" unwind plan and one "call site" unwind plan, track all the different types of unwind plans we can possibly retrieve for each function and have the call-site/non-call-site accessor methods retrieve those. Add a real "fast unwind plan" for x86_64 / i386 -- when doing an unwind through a function, this only has to read the first 4 bytes to tell if the function has a standard prologue sequence. If so, we can use the architecture default unwind plan to backtrace through this function. If we try to retrieve the save location for other registers later on, a real unwind plan will be used. This one is just for doing fast backtraces. Change the compact unwind plan importer to fill in the valid address range it is valid for. Compact unwind, in theory, may have multiple entries for a single function. The FuncUnwinders rewrite includes the start of supporting this correctly. In practice compact unwind encodings are used for the entire range of the function today -- in fact, sometimes the same encoding is used for multiple functions that have the same unwind rules. But I want to handle a single function that has multiple different compact unwind UnwindPlans eventually. llvm-svn: 224689
2014-12-21 18:44:54 +08:00
personality_addr = unwind_plan_sp->GetPersonalityFunctionPtr();
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;
}