[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
|
|
|
//===-- FuncUnwinders.cpp -------------------------------------------------===//
|
2010-09-10 15:49:16 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-09-10 15:49:16 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "lldb/Symbol/FuncUnwinders.h"
|
2011-04-26 02:36:36 +08:00
|
|
|
#include "lldb/Core/Address.h"
|
|
|
|
#include "lldb/Core/AddressRange.h"
|
2015-09-30 21:50:14 +08:00
|
|
|
#include "lldb/Symbol/ArmUnwindInfo.h"
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
#include "lldb/Symbol/CallFrameInfo.h"
|
2014-12-08 11:09:00 +08:00
|
|
|
#include "lldb/Symbol/CompactUnwindInfo.h"
|
2011-04-26 02:36:36 +08:00
|
|
|
#include "lldb/Symbol/DWARFCallFrameInfo.h"
|
2010-09-10 15:49:16 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
FuncUnwinders: Add a new "SymbolFile" unwind plan
Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).
This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.
The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.
Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.
Reviewers: jasonmolenda, clayborg
Subscribers: markmentovai, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D61732
llvm-svn: 360409
2019-05-10 15:54:37 +08:00
|
|
|
#include "lldb/Symbol/SymbolFile.h"
|
2010-09-10 15:49:16 +08:00
|
|
|
#include "lldb/Symbol/UnwindPlan.h"
|
|
|
|
#include "lldb/Symbol/UnwindTable.h"
|
2011-05-12 02:39:18 +08:00
|
|
|
#include "lldb/Target/ABI.h"
|
2012-02-21 08:09:25 +08:00
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
2011-05-12 02:39:18 +08:00
|
|
|
#include "lldb/Target/Process.h"
|
FuncUnwinders: Add a new "SymbolFile" unwind plan
Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).
This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.
The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.
Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.
Reviewers: jasonmolenda, clayborg
Subscribers: markmentovai, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D61732
llvm-svn: 360409
2019-05-10 15:54:37 +08:00
|
|
|
#include "lldb/Target/RegisterContext.h"
|
2017-02-15 03:06:07 +08:00
|
|
|
#include "lldb/Target/RegisterNumber.h"
|
2010-09-10 15:49:16 +08:00
|
|
|
#include "lldb/Target/Target.h"
|
|
|
|
#include "lldb/Target/Thread.h"
|
2011-04-26 05:14:26 +08:00
|
|
|
#include "lldb/Target/UnwindAssembly.h"
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2019-02-12 07:13:08 +08:00
|
|
|
#include <memory>
|
|
|
|
|
2010-09-10 15:49:16 +08:00
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
/// constructor
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2016-05-18 09:59:10 +08:00
|
|
|
FuncUnwinders::FuncUnwinders(UnwindTable &unwind_table, AddressRange range)
|
|
|
|
: 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(),
|
|
|
|
m_unwind_plan_arch_default_sp(),
|
|
|
|
m_unwind_plan_arch_default_at_func_entry_sp(),
|
|
|
|
m_tried_unwind_plan_assembly(false), m_tried_unwind_plan_eh_frame(false),
|
2020-01-08 01:01:59 +08:00
|
|
|
m_tried_unwind_plan_object_file(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),
|
2020-01-08 01:01:59 +08:00
|
|
|
m_tried_unwind_plan_object_file_augmented(false),
|
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),
|
2016-05-18 09:59:10 +08:00
|
|
|
m_tried_unwind_plan_compact_unwind(false),
|
FuncUnwinders: Add a new "SymbolFile" unwind plan
Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).
This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.
The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.
Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.
Reviewers: jasonmolenda, clayborg
Subscribers: markmentovai, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D61732
llvm-svn: 360409
2019-05-10 15:54:37 +08:00
|
|
|
m_tried_unwind_plan_arm_unwind(false),
|
|
|
|
m_tried_unwind_plan_symbol_file(false), m_tried_unwind_fast(false),
|
2016-05-18 09:59:10 +08:00
|
|
|
m_tried_unwind_arch_default(false),
|
|
|
|
m_tried_unwind_arch_default_at_func_entry(false),
|
|
|
|
m_first_non_prologue_insn() {}
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
/// destructor
|
|
|
|
|
2014-11-04 13:28:40 +08:00
|
|
|
FuncUnwinders::~FuncUnwinders() {}
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2019-05-24 17:54:39 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetUnwindPlanAtCallSite(Target &target,
|
|
|
|
Thread &thread) {
|
2016-05-18 09:59:10 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +08:00
|
|
|
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetObjectFileUnwindPlan(target))
|
|
|
|
return plan_sp;
|
2019-05-24 17:54:39 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetSymbolFileUnwindPlan(thread))
|
|
|
|
return plan_sp;
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetDebugFrameUnwindPlan(target))
|
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
|
|
|
return plan_sp;
|
2019-05-27 19:53:24 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetEHFrameUnwindPlan(target))
|
|
|
|
return plan_sp;
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetCompactUnwindUnwindPlan(target))
|
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
|
|
|
return plan_sp;
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetArmUnwindUnwindPlan(target))
|
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
|
|
|
return plan_sp;
|
2015-09-30 21:50:14 +08:00
|
|
|
|
|
|
|
return nullptr;
|
2014-12-21 18:44:54 +08:00
|
|
|
}
|
2011-01-08 08:05:12 +08:00
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetCompactUnwindUnwindPlan(Target &target) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +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)
|
|
|
|
return UnwindPlanSP();
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
m_tried_unwind_plan_compact_unwind = true;
|
|
|
|
if (m_range.GetBaseAddress().IsValid()) {
|
|
|
|
Address current_pc(m_range.GetBaseAddress());
|
|
|
|
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
|
2016-09-07 04:57:50 +08:00
|
|
|
// func
|
2014-12-21 18:44:54 +08:00
|
|
|
}
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
return UnwindPlanSP();
|
|
|
|
}
|
|
|
|
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
lldb::UnwindPlanSP FuncUnwinders::GetObjectFileUnwindPlan(Target &target) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
if (m_unwind_plan_object_file_sp.get() ||
|
|
|
|
m_tried_unwind_plan_object_file)
|
|
|
|
return m_unwind_plan_object_file_sp;
|
|
|
|
|
|
|
|
m_tried_unwind_plan_object_file = true;
|
|
|
|
if (m_range.GetBaseAddress().IsValid()) {
|
|
|
|
CallFrameInfo *object_file_frame = m_unwind_table.GetObjectFileUnwindInfo();
|
|
|
|
if (object_file_frame) {
|
|
|
|
m_unwind_plan_object_file_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
|
|
|
if (!object_file_frame->GetUnwindPlan(m_range,
|
|
|
|
*m_unwind_plan_object_file_sp))
|
|
|
|
m_unwind_plan_object_file_sp.reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return m_unwind_plan_object_file_sp;
|
|
|
|
}
|
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetEHFrameUnwindPlan(Target &target) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2015-09-30 21:50:14 +08:00
|
|
|
if (m_unwind_plan_eh_frame_sp.get() || m_tried_unwind_plan_eh_frame)
|
|
|
|
return m_unwind_plan_eh_frame_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-09-30 21:50:14 +08:00
|
|
|
m_tried_unwind_plan_eh_frame = true;
|
|
|
|
if (m_range.GetBaseAddress().IsValid()) {
|
|
|
|
DWARFCallFrameInfo *eh_frame = m_unwind_table.GetEHFrameInfo();
|
|
|
|
if (eh_frame) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_eh_frame_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
if (!eh_frame->GetUnwindPlan(m_range, *m_unwind_plan_eh_frame_sp))
|
2015-09-30 21:50:14 +08:00
|
|
|
m_unwind_plan_eh_frame_sp.reset();
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-09-30 21:50:14 +08:00
|
|
|
return m_unwind_plan_eh_frame_sp;
|
|
|
|
}
|
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetDebugFrameUnwindPlan(Target &target) {
|
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
|
|
|
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()) {
|
|
|
|
DWARFCallFrameInfo *debug_frame = m_unwind_table.GetDebugFrameInfo();
|
|
|
|
if (debug_frame) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_debug_frame_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
if (!debug_frame->GetUnwindPlan(m_range, *m_unwind_plan_debug_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
|
|
|
m_unwind_plan_debug_frame_sp.reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return m_unwind_plan_debug_frame_sp;
|
|
|
|
}
|
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetArmUnwindUnwindPlan(Target &target) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (m_unwind_plan_arm_unwind_sp.get() || m_tried_unwind_plan_arm_unwind)
|
|
|
|
return m_unwind_plan_arm_unwind_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
m_tried_unwind_plan_arm_unwind = true;
|
|
|
|
if (m_range.GetBaseAddress().IsValid()) {
|
|
|
|
Address current_pc(m_range.GetBaseAddress());
|
|
|
|
ArmUnwindInfo *arm_unwind_info = m_unwind_table.GetArmUnwindInfo();
|
2015-09-30 21:50:14 +08:00
|
|
|
if (arm_unwind_info) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_arm_unwind_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (!arm_unwind_info->GetUnwindPlan(target, current_pc,
|
2015-05-06 23:54:48 +08:00
|
|
|
*m_unwind_plan_arm_unwind_sp))
|
2014-12-21 18:44:54 +08:00
|
|
|
m_unwind_plan_arm_unwind_sp.reset();
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
return m_unwind_plan_arm_unwind_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
FuncUnwinders: Add a new "SymbolFile" unwind plan
Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).
This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.
The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.
Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.
Reviewers: jasonmolenda, clayborg
Subscribers: markmentovai, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D61732
llvm-svn: 360409
2019-05-10 15:54:37 +08:00
|
|
|
namespace {
|
|
|
|
class RegisterContextToInfo: public SymbolFile::RegisterInfoResolver {
|
|
|
|
public:
|
|
|
|
RegisterContextToInfo(RegisterContext &ctx) : m_ctx(ctx) {}
|
|
|
|
|
|
|
|
const RegisterInfo *ResolveName(llvm::StringRef name) const {
|
|
|
|
return m_ctx.GetRegisterInfoByName(name);
|
|
|
|
}
|
|
|
|
const RegisterInfo *ResolveNumber(lldb::RegisterKind kind,
|
|
|
|
uint32_t number) const {
|
|
|
|
return m_ctx.GetRegisterInfo(kind, number);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
RegisterContext &m_ctx;
|
|
|
|
};
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
UnwindPlanSP FuncUnwinders::GetSymbolFileUnwindPlan(Thread &thread) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
if (m_unwind_plan_symbol_file_sp.get() || m_tried_unwind_plan_symbol_file)
|
|
|
|
return m_unwind_plan_symbol_file_sp;
|
|
|
|
|
|
|
|
m_tried_unwind_plan_symbol_file = true;
|
|
|
|
if (SymbolFile *symfile = m_unwind_table.GetSymbolFile()) {
|
|
|
|
m_unwind_plan_symbol_file_sp = symfile->GetUnwindPlan(
|
|
|
|
m_range.GetBaseAddress(),
|
|
|
|
RegisterContextToInfo(*thread.GetRegisterContext()));
|
|
|
|
}
|
|
|
|
return m_unwind_plan_symbol_file_sp;
|
|
|
|
}
|
|
|
|
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
UnwindPlanSP
|
|
|
|
FuncUnwinders::GetObjectFileAugmentedUnwindPlan(Target &target,
|
|
|
|
Thread &thread) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
if (m_unwind_plan_object_file_augmented_sp.get() ||
|
|
|
|
m_tried_unwind_plan_object_file_augmented)
|
|
|
|
return m_unwind_plan_object_file_augmented_sp;
|
|
|
|
|
|
|
|
m_tried_unwind_plan_object_file_augmented = true;
|
|
|
|
|
|
|
|
UnwindPlanSP object_file_unwind_plan = GetObjectFileUnwindPlan(target);
|
|
|
|
if (!object_file_unwind_plan)
|
|
|
|
return m_unwind_plan_object_file_augmented_sp;
|
|
|
|
|
|
|
|
m_unwind_plan_object_file_augmented_sp =
|
|
|
|
std::make_shared<UnwindPlan>(*object_file_unwind_plan);
|
|
|
|
|
|
|
|
// Augment the 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_object_file_augmented_sp)) {
|
|
|
|
m_unwind_plan_object_file_augmented_sp.reset();
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
m_unwind_plan_object_file_augmented_sp.reset();
|
|
|
|
}
|
|
|
|
return m_unwind_plan_object_file_augmented_sp;
|
|
|
|
}
|
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetEHFrameAugmentedUnwindPlan(Target &target,
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
Thread &thread) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (m_unwind_plan_eh_frame_augmented_sp.get() ||
|
|
|
|
m_tried_unwind_plan_eh_frame_augmented)
|
2015-05-06 23:54:48 +08:00
|
|
|
return m_unwind_plan_eh_frame_augmented_sp;
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2018-05-01 00:49:04 +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.
|
2016-05-18 09:59:10 +08:00
|
|
|
if (target.GetArchitecture().GetCore() != ArchSpec::eCore_x86_32_i386 &&
|
|
|
|
target.GetArchitecture().GetCore() != ArchSpec::eCore_x86_64_x86_64 &&
|
2014-12-21 18:44:54 +08:00
|
|
|
target.GetArchitecture().GetCore() != ArchSpec::eCore_x86_64_x86_64h) {
|
|
|
|
m_tried_unwind_plan_eh_frame_augmented = true;
|
2015-05-06 23:54:48 +08:00
|
|
|
return m_unwind_plan_eh_frame_augmented_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2015-05-06 23:54:48 +08:00
|
|
|
m_tried_unwind_plan_eh_frame_augmented = true;
|
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP eh_frame_plan = GetEHFrameUnwindPlan(target);
|
2015-05-06 23:54:48 +08:00
|
|
|
if (!eh_frame_plan)
|
|
|
|
return m_unwind_plan_eh_frame_augmented_sp;
|
|
|
|
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_eh_frame_augmented_sp =
|
|
|
|
std::make_shared<UnwindPlan>(*eh_frame_plan);
|
2015-05-06 23:54:48 +08:00
|
|
|
|
|
|
|
// Augment the eh_frame instructions with epilogue descriptions if necessary
|
2018-05-01 00:49:04 +08:00
|
|
|
// so the UnwindPlan can be used at any instruction in the function.
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-06-24 19:27:32 +08:00
|
|
|
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
|
2015-05-06 23:54:48 +08:00
|
|
|
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();
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
} else {
|
2015-05-06 23:54:48 +08:00
|
|
|
m_unwind_plan_eh_frame_augmented_sp.reset();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
return m_unwind_plan_eh_frame_augmented_sp;
|
|
|
|
}
|
2014-08-26 04:29:09 +08:00
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetDebugFrameAugmentedUnwindPlan(Target &target,
|
|
|
|
Thread &thread) {
|
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
|
|
|
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;
|
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP debug_frame_plan = GetDebugFrameUnwindPlan(target);
|
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 (!debug_frame_plan)
|
|
|
|
return m_unwind_plan_debug_frame_augmented_sp;
|
|
|
|
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_debug_frame_augmented_sp =
|
|
|
|
std::make_shared<UnwindPlan>(*debug_frame_plan);
|
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
|
|
|
|
|
|
|
// Augment the debug_frame instructions with epilogue descriptions if
|
2018-05-01 00:49:04 +08:00
|
|
|
// necessary so the UnwindPlan can be used at any instruction in the
|
|
|
|
// function.
|
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
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetAssemblyUnwindPlan(Target &target,
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
Thread &thread) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (m_unwind_plan_assembly_sp.get() || m_tried_unwind_plan_assembly ||
|
2018-12-15 08:15:33 +08:00
|
|
|
!m_unwind_table.GetAllowAssemblyEmulationUnwindPlans()) {
|
2014-12-21 18:44:54 +08:00
|
|
|
return m_unwind_plan_assembly_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2016-05-04 11:09:40 +08:00
|
|
|
m_tried_unwind_plan_assembly = true;
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2015-06-24 19:27:32 +08:00
|
|
|
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
|
2014-12-21 18:44:54 +08:00
|
|
|
if (assembly_profiler_sp) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_assembly_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (!assembly_profiler_sp->GetNonCallSiteUnwindPlanFromAssembly(
|
|
|
|
m_range, thread, *m_unwind_plan_assembly_sp)) {
|
|
|
|
m_unwind_plan_assembly_sp.reset();
|
2010-10-25 19:12:07 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
return m_unwind_plan_assembly_sp;
|
|
|
|
}
|
|
|
|
|
2016-07-07 07:06:19 +08:00
|
|
|
// This method compares the pc unwind rule in the first row of two UnwindPlans.
|
|
|
|
// If they have the same way of getting the pc value (e.g. "CFA - 8" + "CFA is
|
2018-05-01 00:49:04 +08:00
|
|
|
// sp"), then it will return LazyBoolTrue.
|
2016-07-07 07:06:19 +08:00
|
|
|
LazyBool FuncUnwinders::CompareUnwindPlansForIdenticalInitialPCLocation(
|
|
|
|
Thread &thread, const UnwindPlanSP &a, const UnwindPlanSP &b) {
|
|
|
|
LazyBool plans_are_identical = eLazyBoolCalculate;
|
2014-12-21 18:44:54 +08:00
|
|
|
|
|
|
|
RegisterNumber pc_reg(thread, eRegisterKindGeneric, LLDB_REGNUM_GENERIC_PC);
|
2016-07-07 07:06:19 +08:00
|
|
|
uint32_t pc_reg_lldb_regnum = pc_reg.GetAsKind(eRegisterKindLLDB);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-07-07 07:06:19 +08:00
|
|
|
if (a.get() && b.get()) {
|
|
|
|
UnwindPlan::RowSP a_first_row = a->GetRowAtIndex(0);
|
|
|
|
UnwindPlan::RowSP b_first_row = b->GetRowAtIndex(0);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-07-07 07:06:19 +08:00
|
|
|
if (a_first_row.get() && b_first_row.get()) {
|
|
|
|
UnwindPlan::Row::RegisterLocation a_pc_regloc;
|
|
|
|
UnwindPlan::Row::RegisterLocation b_pc_regloc;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-07-07 07:06:19 +08:00
|
|
|
a_first_row->GetRegisterInfo(pc_reg_lldb_regnum, a_pc_regloc);
|
|
|
|
b_first_row->GetRegisterInfo(pc_reg_lldb_regnum, b_pc_regloc);
|
|
|
|
|
|
|
|
plans_are_identical = eLazyBoolYes;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-07-07 07:06:19 +08:00
|
|
|
if (a_first_row->GetCFAValue() != b_first_row->GetCFAValue()) {
|
|
|
|
plans_are_identical = eLazyBoolNo;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-07-07 07:06:19 +08:00
|
|
|
if (a_pc_regloc != b_pc_regloc) {
|
|
|
|
plans_are_identical = eLazyBoolNo;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-07-07 07:06:19 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-07-07 07:06:19 +08:00
|
|
|
return plans_are_identical;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-07-07 07:06:19 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetUnwindPlanAtNonCallSite(Target &target,
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
Thread &thread) {
|
|
|
|
UnwindPlanSP eh_frame_sp = GetEHFrameUnwindPlan(target);
|
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)
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
eh_frame_sp = GetDebugFrameUnwindPlan(target);
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
if (!eh_frame_sp)
|
|
|
|
eh_frame_sp = GetObjectFileUnwindPlan(target);
|
2016-07-07 07:06:19 +08:00
|
|
|
UnwindPlanSP arch_default_at_entry_sp =
|
2011-09-15 08:44:34 +08:00
|
|
|
GetUnwindPlanArchitectureDefaultAtFunctionEntry(thread);
|
2016-07-07 07:06:19 +08:00
|
|
|
UnwindPlanSP arch_default_sp = GetUnwindPlanArchitectureDefault(thread);
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP assembly_sp = GetAssemblyUnwindPlan(target, thread);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// This point of this code is to detect when a function is using a non-
|
|
|
|
// standard ABI, and the eh_frame correctly describes that alternate ABI.
|
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
|
|
|
// 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
|
2018-05-01 00:49:04 +08:00
|
|
|
// 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.
|
2016-09-07 04:57:50 +08:00
|
|
|
//
|
2016-07-07 07:06:19 +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)
|
2018-05-01 00:49:04 +08:00
|
|
|
// 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
|
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
|
|
|
// available.
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-07-07 07:06:19 +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;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2019-05-24 17:54:39 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetSymbolFileUnwindPlan(thread))
|
|
|
|
return plan_sp;
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetDebugFrameAugmentedUnwindPlan(target, thread))
|
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
|
|
|
return plan_sp;
|
2019-05-27 19:53:24 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetEHFrameAugmentedUnwindPlan(target, thread))
|
|
|
|
return plan_sp;
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
if (UnwindPlanSP plan_sp = GetObjectFileAugmentedUnwindPlan(target, thread))
|
|
|
|
return plan_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-07-07 07:06:19 +08:00
|
|
|
return assembly_sp;
|
2010-09-10 15:49:16 +08:00
|
|
|
}
|
|
|
|
|
2015-06-24 19:27:32 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetUnwindPlanFastUnwind(Target &target,
|
|
|
|
Thread &thread) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (m_unwind_plan_fast_sp.get() || m_tried_unwind_fast)
|
2011-02-15 08:19:15 +08:00
|
|
|
return m_unwind_plan_fast_sp;
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
m_tried_unwind_fast = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
|
|
|
|
if (assembly_profiler_sp) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_fast_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (!assembly_profiler_sp->GetFastUnwindPlan(m_range, thread,
|
|
|
|
*m_unwind_plan_fast_sp)) {
|
|
|
|
m_unwind_plan_fast_sp.reset();
|
2010-09-10 15:49:16 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
return m_unwind_plan_fast_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2011-09-15 08:44:34 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetUnwindPlanArchitectureDefault(Thread &thread) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (m_unwind_plan_arch_default_sp.get() || m_tried_unwind_arch_default)
|
2011-02-15 08:19:15 +08:00
|
|
|
return m_unwind_plan_arch_default_sp;
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
m_tried_unwind_arch_default = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
Address current_pc;
|
|
|
|
ProcessSP process_sp(thread.CalculateProcess());
|
|
|
|
if (process_sp) {
|
|
|
|
ABI *abi = process_sp->GetABI().get();
|
|
|
|
if (abi) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_arch_default_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (!abi->CreateDefaultUnwindPlan(*m_unwind_plan_arch_default_sp)) {
|
|
|
|
m_unwind_plan_arch_default_sp.reset();
|
2011-09-15 08:44:34 +08:00
|
|
|
}
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2011-09-15 08:44:34 +08:00
|
|
|
|
2013-09-24 10:42:54 +08:00
|
|
|
return m_unwind_plan_arch_default_sp;
|
2011-09-15 08:44:34 +08:00
|
|
|
}
|
|
|
|
|
2011-02-15 08:19:15 +08:00
|
|
|
UnwindPlanSP
|
2011-09-15 08:44:34 +08:00
|
|
|
FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry(Thread &thread) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (m_unwind_plan_arch_default_at_func_entry_sp.get() ||
|
|
|
|
m_tried_unwind_arch_default_at_func_entry)
|
|
|
|
return m_unwind_plan_arch_default_at_func_entry_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
m_tried_unwind_arch_default_at_func_entry = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
Address current_pc;
|
|
|
|
ProcessSP process_sp(thread.CalculateProcess());
|
|
|
|
if (process_sp) {
|
|
|
|
ABI *abi = process_sp->GetABI().get();
|
2016-09-07 04:57:50 +08:00
|
|
|
if (abi) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_arch_default_at_func_entry_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2011-09-15 08:44:34 +08:00
|
|
|
if (!abi->CreateFunctionEntryUnwindPlan(
|
2014-12-21 18:44:54 +08:00
|
|
|
*m_unwind_plan_arch_default_at_func_entry_sp)) {
|
|
|
|
m_unwind_plan_arch_default_at_func_entry_sp.reset();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-09-15 08:44:34 +08:00
|
|
|
|
2010-09-10 15:49:16 +08:00
|
|
|
return m_unwind_plan_arch_default_at_func_entry_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2014-05-23 09:48:10 +08:00
|
|
|
Address &FuncUnwinders::GetFirstNonPrologueInsn(Target &target) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-05-23 09:48:10 +08:00
|
|
|
if (m_first_non_prologue_insn.IsValid())
|
2010-09-10 15:49:16 +08:00
|
|
|
return m_first_non_prologue_insn;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-02-21 08:09:25 +08:00
|
|
|
ExecutionContext exe_ctx(target.shared_from_this(), false);
|
2015-06-24 19:27:32 +08:00
|
|
|
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
|
2014-05-23 09:48:10 +08:00
|
|
|
if (assembly_profiler_sp)
|
|
|
|
assembly_profiler_sp->FirstNonPrologueInsn(m_range, exe_ctx,
|
2010-09-10 15:49:16 +08:00
|
|
|
m_first_non_prologue_insn);
|
|
|
|
return m_first_non_prologue_insn;
|
|
|
|
}
|
|
|
|
|
|
|
|
const Address &FuncUnwinders::GetFunctionStartAddress() const {
|
|
|
|
return m_range.GetBaseAddress();
|
|
|
|
}
|
|
|
|
|
2014-05-23 09:48:10 +08:00
|
|
|
lldb::UnwindAssemblySP
|
2015-06-24 19:27:32 +08:00
|
|
|
FuncUnwinders::GetUnwindAssemblyProfiler(Target &target) {
|
2014-05-23 09:48:10 +08:00
|
|
|
UnwindAssemblySP assembly_profiler_sp;
|
2019-01-03 18:37:19 +08:00
|
|
|
if (ArchSpec arch = m_unwind_table.GetArchitecture()) {
|
2015-06-24 19:27:32 +08:00
|
|
|
arch.MergeFrom(target.GetArchitecture());
|
2014-05-23 09:48:10 +08:00
|
|
|
assembly_profiler_sp = UnwindAssembly::FindPlugin(arch);
|
|
|
|
}
|
|
|
|
return assembly_profiler_sp;
|
|
|
|
}
|
2014-11-18 10:27:42 +08:00
|
|
|
|
2014-12-08 11:09:00 +08:00
|
|
|
Address FuncUnwinders::GetLSDAAddress(Target &target) {
|
2014-11-18 10:27:42 +08:00
|
|
|
Address lsda_addr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP unwind_plan_sp = GetEHFrameUnwindPlan(target);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (unwind_plan_sp.get() == nullptr) {
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
unwind_plan_sp = GetCompactUnwindUnwindPlan(target);
|
2014-12-21 18:44:54 +08:00
|
|
|
}
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
if (unwind_plan_sp.get() == nullptr) {
|
|
|
|
unwind_plan_sp = GetObjectFileUnwindPlan(target);
|
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
if (unwind_plan_sp.get() && unwind_plan_sp->GetLSDAAddress().IsValid()) {
|
|
|
|
lsda_addr = unwind_plan_sp->GetLSDAAddress();
|
2014-11-18 10:27:42 +08:00
|
|
|
}
|
|
|
|
return lsda_addr;
|
|
|
|
}
|
|
|
|
|
2014-12-08 11:09:00 +08:00
|
|
|
Address FuncUnwinders::GetPersonalityRoutinePtrAddress(Target &target) {
|
2014-11-18 10:27:42 +08:00
|
|
|
Address personality_addr;
|
|
|
|
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
UnwindPlanSP unwind_plan_sp = GetEHFrameUnwindPlan(target);
|
2014-12-21 18:44:54 +08:00
|
|
|
if (unwind_plan_sp.get() == nullptr) {
|
FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
2019-04-23 17:57:14 +08:00
|
|
|
unwind_plan_sp = GetCompactUnwindUnwindPlan(target);
|
2014-12-21 18:44:54 +08:00
|
|
|
}
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
if (unwind_plan_sp.get() == nullptr) {
|
|
|
|
unwind_plan_sp = GetObjectFileUnwindPlan(target);
|
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
if (unwind_plan_sp.get() &&
|
|
|
|
unwind_plan_sp->GetPersonalityFunctionPtr().IsValid()) {
|
|
|
|
personality_addr = unwind_plan_sp->GetPersonalityFunctionPtr();
|
2014-11-18 10:27:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return personality_addr;
|
|
|
|
}
|