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

483 lines
19 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.
//
//===----------------------------------------------------------------------===//
#include "lldb/Symbol/FuncUnwinders.h"
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
#include "lldb/Core/Address.h"
#include "lldb/Core/AddressRange.h"
Add support for .ARM.exidx unwind information .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
2015-09-30 21:50:14 +08:00
#include "lldb/Symbol/ArmUnwindInfo.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"
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
#include "lldb/Symbol/DWARFCallFrameInfo.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"
Remove dependencies from Utility to Core and Target. With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
2017-02-15 03:06:07 +08:00
#include "lldb/Target/RegisterNumber.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/Target.h"
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
#include "lldb/Target/Thread.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
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
FuncUnwinders::FuncUnwinders(UnwindTable &unwind_table, AddressRange range)
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
: m_unwind_table(unwind_table), m_range(range), m_mutex(),
m_unwind_plan_assembly_sp(), m_unwind_plan_eh_frame_sp(),
m_unwind_plan_eh_frame_augmented_sp(), m_unwind_plan_compact_unwind(),
m_unwind_plan_arm_unwind_sp(), m_unwind_plan_fast_sp(),
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
m_unwind_plan_arch_default_sp(),
m_unwind_plan_arch_default_at_func_entry_sp(),
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
m_tried_unwind_plan_assembly(false), m_tried_unwind_plan_eh_frame(false),
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
m_tried_unwind_plan_debug_frame(false),
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
m_tried_unwind_plan_eh_frame_augmented(false),
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
m_tried_unwind_plan_debug_frame_augmented(false),
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
m_tried_unwind_plan_compact_unwind(false),
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
m_tried_unwind_plan_arm_unwind(false), m_tried_unwind_fast(false),
remove use of Mutex in favour of std::{,recursive_}mutex This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2016-05-18 09:59:10 +08:00
m_tried_unwind_arch_default(false),
m_tried_unwind_arch_default_at_func_entry(false),
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
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
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
//------------------------------------------------
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP FuncUnwinders::GetUnwindPlanAtCallSite(Target &target,
int current_offset) {
std::lock_guard<std::recursive_mutex> guard(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
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
if (UnwindPlanSP plan_sp = GetEHFrameUnwindPlan(target, current_offset))
return plan_sp;
if (UnwindPlanSP plan_sp = GetDebugFrameUnwindPlan(target, current_offset))
return plan_sp;
if (UnwindPlanSP plan_sp = GetCompactUnwindUnwindPlan(target, current_offset))
return plan_sp;
if (UnwindPlanSP plan_sp = GetArmUnwindUnwindPlan(target, current_offset))
return plan_sp;
Add support for .ARM.exidx unwind information .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
2015-09-30 21:50:14 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return nullptr;
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
}
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP FuncUnwinders::GetCompactUnwindUnwindPlan(Target &target,
int current_offset) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
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)
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
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)) {
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
}
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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return 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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP FuncUnwinders::GetEHFrameUnwindPlan(Target &target,
int current_offset) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (m_unwind_plan_eh_frame_sp.get() || m_tried_unwind_plan_eh_frame)
return m_unwind_plan_eh_frame_sp;
m_tried_unwind_plan_eh_frame = 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_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();
Add support for .ARM.exidx unwind information .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
2015-09-30 21:50:14 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return m_unwind_plan_eh_frame_sp;
Add support for .ARM.exidx unwind information .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
2015-09-30 21:50:14 +08:00
}
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
UnwindPlanSP FuncUnwinders::GetDebugFrameUnwindPlan(Target &target,
int current_offset) {
std::lock_guard<std::recursive_mutex> guard(m_mutex);
if (m_unwind_plan_debug_frame_sp || m_tried_unwind_plan_debug_frame)
return m_unwind_plan_debug_frame_sp;
m_tried_unwind_plan_debug_frame = 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 *debug_frame = m_unwind_table.GetDebugFrameInfo();
if (debug_frame) {
m_unwind_plan_debug_frame_sp.reset(
new UnwindPlan(lldb::eRegisterKindGeneric));
if (!debug_frame->GetUnwindPlan(current_pc,
*m_unwind_plan_debug_frame_sp))
m_unwind_plan_debug_frame_sp.reset();
}
}
return m_unwind_plan_debug_frame_sp;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP FuncUnwinders::GetArmUnwindUnwindPlan(Target &target,
int current_offset) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (m_unwind_plan_arm_unwind_sp.get() || m_tried_unwind_plan_arm_unwind)
return m_unwind_plan_arm_unwind_sp;
m_tried_unwind_plan_arm_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);
ArmUnwindInfo *arm_unwind_info = m_unwind_table.GetArmUnwindInfo();
if (arm_unwind_info) {
m_unwind_plan_arm_unwind_sp.reset(
new UnwindPlan(lldb::eRegisterKindGeneric));
if (!arm_unwind_info->GetUnwindPlan(target, current_pc,
*m_unwind_plan_arm_unwind_sp))
m_unwind_plan_arm_unwind_sp.reset();
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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return m_unwind_plan_arm_unwind_sp;
}
UnwindPlanSP FuncUnwinders::GetEHFrameAugmentedUnwindPlan(Target &target,
Thread &thread,
int current_offset) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (m_unwind_plan_eh_frame_augmented_sp.get() ||
m_tried_unwind_plan_eh_frame_augmented)
return m_unwind_plan_eh_frame_augmented_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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
// 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) {
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_plan_eh_frame_augmented = true;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return m_unwind_plan_eh_frame_augmented_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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
m_tried_unwind_plan_eh_frame_augmented = true;
Simplify FuncUnwinders::GetEHFrameAugmentedUnwindPlan Summary: GetEHFrameAugmentedUnwindPlan duplicated the work of GetEHFrameUnwindPlan in getting the original plan from DWARF CFI. This changes the function to call GetEHFrameUnwindPlan instead of doing all the work itself. A copy constructor is added to UnwindPlan to enable plan copying. Test Plan: No regressions on linux test suite. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9369 llvm-svn: 236607
2015-05-06 23:54:48 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP eh_frame_plan = GetEHFrameUnwindPlan(target, current_offset);
if (!eh_frame_plan)
return m_unwind_plan_eh_frame_augmented_sp;
Simplify FuncUnwinders::GetEHFrameAugmentedUnwindPlan Summary: GetEHFrameAugmentedUnwindPlan duplicated the work of GetEHFrameUnwindPlan in getting the original plan from DWARF CFI. This changes the function to call GetEHFrameUnwindPlan instead of doing all the work itself. A copy constructor is added to UnwindPlan to enable plan copying. Test Plan: No regressions on linux test suite. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9369 llvm-svn: 236607
2015-05-06 23:54:48 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
m_unwind_plan_eh_frame_augmented_sp.reset(new UnwindPlan(*eh_frame_plan));
Simplify FuncUnwinders::GetEHFrameAugmentedUnwindPlan Summary: GetEHFrameAugmentedUnwindPlan duplicated the work of GetEHFrameUnwindPlan in getting the original plan from DWARF CFI. This changes the function to call GetEHFrameUnwindPlan instead of doing all the work itself. A copy constructor is added to UnwindPlan to enable plan copying. Test Plan: No regressions on linux test suite. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9369 llvm-svn: 236607
2015-05-06 23:54:48 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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(target));
if (assembly_profiler_sp) {
if (!assembly_profiler_sp->AugmentUnwindPlanFromCallSite(
m_range, thread, *m_unwind_plan_eh_frame_augmented_sp)) {
m_unwind_plan_eh_frame_augmented_sp.reset();
Simplify FuncUnwinders::GetEHFrameAugmentedUnwindPlan Summary: GetEHFrameAugmentedUnwindPlan duplicated the work of GetEHFrameUnwindPlan in getting the original plan from DWARF CFI. This changes the function to call GetEHFrameUnwindPlan instead of doing all the work itself. A copy constructor is added to UnwindPlan to enable plan copying. Test Plan: No regressions on linux test suite. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9369 llvm-svn: 236607
2015-05-06 23:54:48 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
} else {
m_unwind_plan_eh_frame_augmented_sp.reset();
}
return m_unwind_plan_eh_frame_augmented_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
}
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
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
UnwindPlanSP
FuncUnwinders::GetDebugFrameAugmentedUnwindPlan(Target &target, Thread &thread,
int current_offset) {
std::lock_guard<std::recursive_mutex> guard(m_mutex);
if (m_unwind_plan_debug_frame_augmented_sp.get() ||
m_tried_unwind_plan_debug_frame_augmented)
return m_unwind_plan_debug_frame_augmented_sp;
// Only supported on x86 architectures where we get debug_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_debug_frame_augmented = true;
return m_unwind_plan_debug_frame_augmented_sp;
}
m_tried_unwind_plan_debug_frame_augmented = true;
UnwindPlanSP debug_frame_plan =
GetDebugFrameUnwindPlan(target, current_offset);
if (!debug_frame_plan)
return m_unwind_plan_debug_frame_augmented_sp;
m_unwind_plan_debug_frame_augmented_sp.reset(
new UnwindPlan(*debug_frame_plan));
// Augment the debug_frame instructions with epilogue descriptions if
// necessary so the UnwindPlan can be used at any instruction in the function.
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
if (assembly_profiler_sp) {
if (!assembly_profiler_sp->AugmentUnwindPlanFromCallSite(
m_range, thread, *m_unwind_plan_debug_frame_augmented_sp)) {
m_unwind_plan_debug_frame_augmented_sp.reset();
}
} else
m_unwind_plan_debug_frame_augmented_sp.reset();
return m_unwind_plan_debug_frame_augmented_sp;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP FuncUnwinders::GetAssemblyUnwindPlan(Target &target,
Thread &thread,
int current_offset) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (m_unwind_plan_assembly_sp.get() || m_tried_unwind_plan_assembly ||
m_unwind_table.GetAllowAssemblyEmulationUnwindPlans() == false) {
return m_unwind_plan_assembly_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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
m_tried_unwind_plan_assembly = true;
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
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();
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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return m_unwind_plan_assembly_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
}
Enhance FuncUnwinders::GetUnwindPlanAtNonCallSite to detect when we may be in a function that is non-ABI conformant, and the eh_frame instructions correctly describe how to unwind out of this function, but the assembly parsing / arch default unwind plans would be incorrect. This is to address a problem that Ravitheja Addepally reported in http://reviews.llvm.org/D21221 - I wanted to try handling the problem with this approach which I think may be more generally helpful, Ravitheja tested it and said it solves the problem on Linux/FreeBSD. Ravi has a test case in http://reviews.llvm.org/D21221 that will be committed separately. Thanks for all the help on this one, Ravi. llvm-svn: 274700
2016-07-07 07:06:19 +08:00
// This method compares the pc unwind rule in the first row of two UnwindPlans.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
// If they have the same way of getting the pc value (e.g. "CFA - 8" + "CFA is
// sp"),
Enhance FuncUnwinders::GetUnwindPlanAtNonCallSite to detect when we may be in a function that is non-ABI conformant, and the eh_frame instructions correctly describe how to unwind out of this function, but the assembly parsing / arch default unwind plans would be incorrect. This is to address a problem that Ravitheja Addepally reported in http://reviews.llvm.org/D21221 - I wanted to try handling the problem with this approach which I think may be more generally helpful, Ravitheja tested it and said it solves the problem on Linux/FreeBSD. Ravi has a test case in http://reviews.llvm.org/D21221 that will be committed separately. Thanks for all the help on this one, Ravi. llvm-svn: 274700
2016-07-07 07:06:19 +08:00
// then it will return LazyBoolTrue.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
LazyBool FuncUnwinders::CompareUnwindPlansForIdenticalInitialPCLocation(
Thread &thread, const UnwindPlanSP &a, const UnwindPlanSP &b) {
LazyBool plans_are_identical = eLazyBoolCalculate;
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
RegisterNumber pc_reg(thread, eRegisterKindGeneric, LLDB_REGNUM_GENERIC_PC);
uint32_t pc_reg_lldb_regnum = pc_reg.GetAsKind(eRegisterKindLLDB);
if (a.get() && b.get()) {
UnwindPlan::RowSP a_first_row = a->GetRowAtIndex(0);
UnwindPlan::RowSP b_first_row = b->GetRowAtIndex(0);
if (a_first_row.get() && b_first_row.get()) {
UnwindPlan::Row::RegisterLocation a_pc_regloc;
UnwindPlan::Row::RegisterLocation b_pc_regloc;
a_first_row->GetRegisterInfo(pc_reg_lldb_regnum, a_pc_regloc);
b_first_row->GetRegisterInfo(pc_reg_lldb_regnum, b_pc_regloc);
Enhance FuncUnwinders::GetUnwindPlanAtNonCallSite to detect when we may be in a function that is non-ABI conformant, and the eh_frame instructions correctly describe how to unwind out of this function, but the assembly parsing / arch default unwind plans would be incorrect. This is to address a problem that Ravitheja Addepally reported in http://reviews.llvm.org/D21221 - I wanted to try handling the problem with this approach which I think may be more generally helpful, Ravitheja tested it and said it solves the problem on Linux/FreeBSD. Ravi has a test case in http://reviews.llvm.org/D21221 that will be committed separately. Thanks for all the help on this one, Ravi. llvm-svn: 274700
2016-07-07 07:06:19 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
plans_are_identical = eLazyBoolYes;
if (a_first_row->GetCFAValue() != b_first_row->GetCFAValue()) {
plans_are_identical = eLazyBoolNo;
}
if (a_pc_regloc != b_pc_regloc) {
plans_are_identical = eLazyBoolNo;
}
Enhance FuncUnwinders::GetUnwindPlanAtNonCallSite to detect when we may be in a function that is non-ABI conformant, and the eh_frame instructions correctly describe how to unwind out of this function, but the assembly parsing / arch default unwind plans would be incorrect. This is to address a problem that Ravitheja Addepally reported in http://reviews.llvm.org/D21221 - I wanted to try handling the problem with this approach which I think may be more generally helpful, Ravitheja tested it and said it solves the problem on Linux/FreeBSD. Ravi has a test case in http://reviews.llvm.org/D21221 that will be committed separately. Thanks for all the help on this one, Ravi. llvm-svn: 274700
2016-07-07 07:06:19 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return plans_are_identical;
}
Enhance FuncUnwinders::GetUnwindPlanAtNonCallSite to detect when we may be in a function that is non-ABI conformant, and the eh_frame instructions correctly describe how to unwind out of this function, but the assembly parsing / arch default unwind plans would be incorrect. This is to address a problem that Ravitheja Addepally reported in http://reviews.llvm.org/D21221 - I wanted to try handling the problem with this approach which I think may be more generally helpful, Ravitheja tested it and said it solves the problem on Linux/FreeBSD. Ravi has a test case in http://reviews.llvm.org/D21221 that will be committed separately. Thanks for all the help on this one, Ravi. llvm-svn: 274700
2016-07-07 07:06:19 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP FuncUnwinders::GetUnwindPlanAtNonCallSite(Target &target,
Thread &thread,
int current_offset) {
UnwindPlanSP eh_frame_sp = GetEHFrameUnwindPlan(target, current_offset);
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
if (!eh_frame_sp)
eh_frame_sp = GetDebugFrameUnwindPlan(target, current_offset);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP arch_default_at_entry_sp =
GetUnwindPlanArchitectureDefaultAtFunctionEntry(thread);
UnwindPlanSP arch_default_sp = GetUnwindPlanArchitectureDefault(thread);
UnwindPlanSP assembly_sp =
GetAssemblyUnwindPlan(target, thread, current_offset);
// This point of this code is to detect when a function is using a
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
// non-standard ABI, and the eh_frame correctly describes that alternate ABI.
// This is addressing a specific situation on x86_64 linux systems where one
// function in a library pushes a value on the stack and jumps to another
// function. So using an assembly instruction based unwind will not work when
// you're in the second function - the stack has been modified in a non-ABI
// way. But we have eh_frame that correctly describes how to unwind from this
// location. So we're looking to see if the initial pc register save location
// from the eh_frame is different from the assembly unwind, the arch default
// unwind, and the arch default at initial function entry.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
//
// We may have eh_frame that describes the entire function -- or we may have
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
// eh_frame that only describes the unwind after the prologue has executed --
// so we need to check both the arch default (once the prologue has executed)
// and the arch default at initial function entry. And we may be running on a
// target where we have only some of the assembly/arch default unwind plans
// available.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (CompareUnwindPlansForIdenticalInitialPCLocation(
thread, eh_frame_sp, arch_default_at_entry_sp) == eLazyBoolNo &&
CompareUnwindPlansForIdenticalInitialPCLocation(
thread, eh_frame_sp, arch_default_sp) == eLazyBoolNo &&
CompareUnwindPlansForIdenticalInitialPCLocation(
thread, assembly_sp, arch_default_sp) == eLazyBoolNo) {
return eh_frame_sp;
}
Add debug_frame section support Summary: This is a beefed-up version of D33504, which adds support for dwarf 4 debug_frame section format. The main difference here is that the decision whether to use eh_frame or debug_frame is done on a per-function basis instead of per-object file. This is necessary because one module can contain both sections (for example, the start files added by the linker will typically pull in eh_frame), but we want to be able to access both, for maximum information. I also add unit test for parsing various CFI formats (eh_frame, debug_frame v3 and debug_frame v4). Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D34613 llvm-svn: 306397
2017-06-27 19:16:26 +08:00
if (UnwindPlanSP plan_sp =
GetEHFrameAugmentedUnwindPlan(target, thread, current_offset))
return plan_sp;
if (UnwindPlanSP plan_sp =
GetDebugFrameAugmentedUnwindPlan(target, thread, current_offset))
return plan_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return assembly_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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP FuncUnwinders::GetUnwindPlanFastUnwind(Target &target,
Thread &thread) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (m_unwind_plan_fast_sp.get() || m_tried_unwind_fast)
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
m_tried_unwind_fast = true;
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
if (assembly_profiler_sp) {
m_unwind_plan_fast_sp.reset(new UnwindPlan(lldb::eRegisterKindGeneric));
if (!assembly_profiler_sp->GetFastUnwindPlan(m_range, thread,
*m_unwind_plan_fast_sp)) {
m_unwind_plan_fast_sp.reset();
The first part of an lldb native stack unwinder. The Unwind and RegisterContext subclasses still need to be finished; none of this code is used by lldb at this point (unless you call into it by hand). The ObjectFile class now has an UnwindTable object. The UnwindTable object has a series of FuncUnwinders objects (Function Unwinders) -- one for each function in that ObjectFile we've backtraced through during this debug session. The FuncUnwinders object has a few different UnwindPlans. UnwindPlans are a generic way of describing how to find the canonical address of a given function's stack frame (the CFA idea from DWARF/eh_frame) and how to restore the caller frame's register values, if they have been saved by this function. UnwindPlans are created from different sources. One source is the eh_frame exception handling information generated by the compiler for unwinding an exception throw. Another source is an assembly language inspection class (UnwindAssemblyProfiler, uses the Plugin architecture) which looks at the instructions in the funciton prologue and describes the stack movements/register saves that are done. Two additional types of UnwindPlans that are worth noting are the "fast" stack UnwindPlan which is useful for making a first pass over a thread's stack, determining how many stack frames there are and retrieving the pc and CFA values for each frame (enough to create StackFrameIDs). Only a minimal set of registers is recovered during a fast stack walk. The final UnwindPlan is an architectural default unwind plan. These are provided by the ArchDefaultUnwindPlan class (which uses the plugin architecture). When no symbol/function address range can be found for a given pc value -- when we have no eh_frame information and when we don't have a start address so we can't examine the assembly language instrucitons -- we have to make a best guess about how to unwind. That's when we use the architectural default UnwindPlan. On x86_64, this would be to assume that rbp is used as a stack pointer and we can use that to find the caller's frame pointer and pc value. It's a last-ditch best guess about how to unwind out of a frame. There are heuristics about when to use one UnwindPlan versues the other -- this will all happen in the still-begin-written UnwindLLDB subclass of Unwind which runs the UnwindPlans. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP FuncUnwinders::GetUnwindPlanArchitectureDefault(Thread &thread) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (m_unwind_plan_arch_default_sp.get() || m_tried_unwind_arch_default)
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
m_tried_unwind_arch_default = true;
Address current_pc;
ProcessSP process_sp(thread.CalculateProcess());
if (process_sp) {
ABI *abi = process_sp->GetABI().get();
if (abi) {
m_unwind_plan_arch_default_sp.reset(
new UnwindPlan(lldb::eRegisterKindGeneric));
if (!abi->CreateDefaultUnwindPlan(*m_unwind_plan_arch_default_sp)) {
m_unwind_plan_arch_default_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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return m_unwind_plan_arch_default_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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
UnwindPlanSP
FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry(Thread &thread) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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;
m_tried_unwind_arch_default_at_func_entry = true;
Address current_pc;
ProcessSP process_sp(thread.CalculateProcess());
if (process_sp) {
ABI *abi = process_sp->GetABI().get();
if (abi) {
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)) {
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return m_unwind_plan_arch_default_at_func_entry_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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Address &FuncUnwinders::GetFirstNonPrologueInsn(Target &target) {
Fix a race condition in FuncUnwinders where the mutex was being acquired only after checking if the ivar shared pointer was already filled in. But when I assign an UnwindPlan object to the shared pointer, I assign an empty object and then fill it in. That leaves a window where another thread could get the shared pointer to the empty (but quickly being-filled-in) object and lead to a crash. Also two changes from Greg for correctness on the TestMultipleDebuggers test case. <rdar://problem/30564102> llvm-svn: 296084
2017-02-24 11:35:46 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (m_first_non_prologue_insn.IsValid())
The first part of an lldb native stack unwinder. The Unwind and RegisterContext subclasses still need to be finished; none of this code is used by lldb at this point (unless you call into it by hand). The ObjectFile class now has an UnwindTable object. The UnwindTable object has a series of FuncUnwinders objects (Function Unwinders) -- one for each function in that ObjectFile we've backtraced through during this debug session. The FuncUnwinders object has a few different UnwindPlans. UnwindPlans are a generic way of describing how to find the canonical address of a given function's stack frame (the CFA idea from DWARF/eh_frame) and how to restore the caller frame's register values, if they have been saved by this function. UnwindPlans are created from different sources. One source is the eh_frame exception handling information generated by the compiler for unwinding an exception throw. Another source is an assembly language inspection class (UnwindAssemblyProfiler, uses the Plugin architecture) which looks at the instructions in the funciton prologue and describes the stack movements/register saves that are done. Two additional types of UnwindPlans that are worth noting are the "fast" stack UnwindPlan which is useful for making a first pass over a thread's stack, determining how many stack frames there are and retrieving the pc and CFA values for each frame (enough to create StackFrameIDs). Only a minimal set of registers is recovered during a fast stack walk. The final UnwindPlan is an architectural default unwind plan. These are provided by the ArchDefaultUnwindPlan class (which uses the plugin architecture). When no symbol/function address range can be found for a given pc value -- when we have no eh_frame information and when we don't have a start address so we can't examine the assembly language instrucitons -- we have to make a best guess about how to unwind. That's when we use the architectural default UnwindPlan. On x86_64, this would be to assume that rbp is used as a stack pointer and we can use that to find the caller's frame pointer and pc value. It's a last-ditch best guess about how to unwind out of a frame. There are heuristics about when to use one UnwindPlan versues the other -- this will all happen in the still-begin-written UnwindLLDB subclass of Unwind which runs the UnwindPlans. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
return m_first_non_prologue_insn;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
ExecutionContext exe_ctx(target.shared_from_this(), false);
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
if (assembly_profiler_sp)
assembly_profiler_sp->FirstNonPrologueInsn(m_range, exe_ctx,
m_first_non_prologue_insn);
return 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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
const Address &FuncUnwinders::GetFunctionStartAddress() const {
return m_range.GetBaseAddress();
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
}
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
FuncUnwinders::GetUnwindAssemblyProfiler(Target &target) {
UnwindAssemblySP assembly_profiler_sp;
ArchSpec arch;
if (m_unwind_table.GetArchitecture(arch)) {
arch.MergeFrom(target.GetArchitecture());
assembly_profiler_sp = UnwindAssembly::FindPlugin(arch);
}
return assembly_profiler_sp;
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
}
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Address FuncUnwinders::GetLSDAAddress(Target &target) {
Address lsda_addr;
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->GetLSDAAddress().IsValid()) {
lsda_addr = unwind_plan_sp->GetLSDAAddress();
}
return lsda_addr;
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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Address FuncUnwinders::GetPersonalityRoutinePtrAddress(Target &target) {
Address personality_addr;
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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()) {
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return personality_addr;
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
}