2010-09-10 15:49:16 +08:00
|
|
|
//===-- FuncUnwinders.cpp ----------------------------------*- C++ -*-===//
|
|
|
|
//
|
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"
|
2016-09-07 04:57:50 +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"
|
2014-12-08 11:09:00 +08:00
|
|
|
#include "lldb/Symbol/CompactUnwindInfo.h"
|
2016-09-07 04:57:50 +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"
|
2016-09-07 04:57:50 +08:00
|
|
|
#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)
|
2016-09-07 04:57:50 +08:00
|
|
|
: m_unwind_table(unwind_table), m_range(range), m_mutex(),
|
|
|
|
m_unwind_plan_assembly_sp(), m_unwind_plan_eh_frame_sp(),
|
|
|
|
m_unwind_plan_eh_frame_augmented_sp(), m_unwind_plan_compact_unwind(),
|
|
|
|
m_unwind_plan_arm_unwind_sp(), m_unwind_plan_fast_sp(),
|
2016-05-18 09:59:10 +08:00
|
|
|
m_unwind_plan_arch_default_sp(),
|
|
|
|
m_unwind_plan_arch_default_at_func_entry_sp(),
|
2016-09-07 04:57:50 +08:00
|
|
|
m_tried_unwind_plan_assembly(false), m_tried_unwind_plan_eh_frame(false),
|
Add debug_frame section support
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
2017-06-27 19:16:26 +08:00
|
|
|
m_tried_unwind_plan_debug_frame(false),
|
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),
|
2016-09-07 04:57:50 +08:00
|
|
|
m_first_non_prologue_insn() {}
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2014-12-21 18:44:54 +08:00
|
|
|
/// destructor
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
FuncUnwinders::~FuncUnwinders() {}
|
2010-09-10 15:49:16 +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::GetUnwindPlanAtCallSite(Target &target) {
|
2016-09-07 04:57:50 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2014-12-21 18:44:54 +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
|
|
|
if (UnwindPlanSP plan_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
|
|
|
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;
|
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
|
|
|
|
2016-09-07 04:57:50 +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);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (m_unwind_plan_compact_unwind.size() > 0)
|
|
|
|
return m_unwind_plan_compact_unwind[0]; // FIXME support multiple compact
|
|
|
|
// unwind plans for one func
|
|
|
|
if (m_tried_unwind_plan_compact_unwind)
|
2014-12-21 18:44:54 +08:00
|
|
|
return UnwindPlanSP();
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
m_tried_unwind_plan_compact_unwind = true;
|
|
|
|
if (m_range.GetBaseAddress().IsValid()) {
|
|
|
|
Address current_pc(m_range.GetBaseAddress());
|
|
|
|
CompactUnwindInfo *compact_unwind = m_unwind_table.GetCompactUnwindInfo();
|
|
|
|
if (compact_unwind) {
|
|
|
|
UnwindPlanSP unwind_plan_sp(new UnwindPlan(lldb::eRegisterKindGeneric));
|
|
|
|
if (compact_unwind->GetUnwindPlan(target, current_pc, *unwind_plan_sp)) {
|
|
|
|
m_unwind_plan_compact_unwind.push_back(unwind_plan_sp);
|
|
|
|
return m_unwind_plan_compact_unwind[0]; // FIXME support multiple
|
|
|
|
// compact unwind plans for one
|
|
|
|
// func
|
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return UnwindPlanSP();
|
2014-12-21 18:44:54 +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::GetEHFrameUnwindPlan(Target &target) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (m_unwind_plan_eh_frame_sp.get() || m_tried_unwind_plan_eh_frame)
|
|
|
|
return m_unwind_plan_eh_frame_sp;
|
|
|
|
|
|
|
|
m_tried_unwind_plan_eh_frame = true;
|
|
|
|
if (m_range.GetBaseAddress().IsValid()) {
|
|
|
|
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))
|
2016-09-07 04:57:50 +08:00
|
|
|
m_unwind_plan_eh_frame_sp.reset();
|
2015-09-30 21:50:14 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return m_unwind_plan_eh_frame_sp;
|
2015-09-30 21:50:14 +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::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);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (m_unwind_plan_arm_unwind_sp.get() || m_tried_unwind_plan_arm_unwind)
|
|
|
|
return m_unwind_plan_arm_unwind_sp;
|
|
|
|
|
|
|
|
m_tried_unwind_plan_arm_unwind = true;
|
|
|
|
if (m_range.GetBaseAddress().IsValid()) {
|
|
|
|
Address current_pc(m_range.GetBaseAddress());
|
|
|
|
ArmUnwindInfo *arm_unwind_info = m_unwind_table.GetArmUnwindInfo();
|
|
|
|
if (arm_unwind_info) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_arm_unwind_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!arm_unwind_info->GetUnwindPlan(target, current_pc,
|
|
|
|
*m_unwind_plan_arm_unwind_sp))
|
|
|
|
m_unwind_plan_arm_unwind_sp.reset();
|
2014-12-21 18:44:54 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return m_unwind_plan_arm_unwind_sp;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +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);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (m_unwind_plan_eh_frame_augmented_sp.get() ||
|
|
|
|
m_tried_unwind_plan_eh_frame_augmented)
|
|
|
|
return m_unwind_plan_eh_frame_augmented_sp;
|
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-09-07 04:57:50 +08:00
|
|
|
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) {
|
2014-12-21 18:44:54 +08:00
|
|
|
m_tried_unwind_plan_eh_frame_augmented = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
return m_unwind_plan_eh_frame_augmented_sp;
|
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
m_tried_unwind_plan_eh_frame_augmented = true;
|
2015-05-06 23:54:48 +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 eh_frame_plan = GetEHFrameUnwindPlan(target);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!eh_frame_plan)
|
|
|
|
return m_unwind_plan_eh_frame_augmented_sp;
|
2015-05-06 23:54:48 +08:00
|
|
|
|
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
|
|
|
|
2016-09-07 04:57:50 +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
|
|
|
|
|
|
|
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
|
|
|
|
if (assembly_profiler_sp) {
|
|
|
|
if (!assembly_profiler_sp->AugmentUnwindPlanFromCallSite(
|
|
|
|
m_range, thread, *m_unwind_plan_eh_frame_augmented_sp)) {
|
|
|
|
m_unwind_plan_eh_frame_augmented_sp.reset();
|
2015-05-06 23:54:48 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
} else {
|
|
|
|
m_unwind_plan_eh_frame_augmented_sp.reset();
|
|
|
|
}
|
|
|
|
return m_unwind_plan_eh_frame_augmented_sp;
|
2014-12-21 18:44:54 +08:00
|
|
|
}
|
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;
|
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +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);
|
2016-09-07 04:57:50 +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()) {
|
2016-09-07 04:57:50 +08:00
|
|
|
return m_unwind_plan_assembly_sp;
|
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
m_tried_unwind_plan_assembly = true;
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
|
|
|
|
if (assembly_profiler_sp) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_assembly_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2016-09-07 04:57:50 +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
|
|
|
}
|
|
|
|
return m_unwind_plan_assembly_sp;
|
2014-12-21 18:44:54 +08:00
|
|
|
}
|
|
|
|
|
2016-07-07 07:06:19 +08:00
|
|
|
// This method compares the pc unwind rule in the first row of two UnwindPlans.
|
2016-09-07 04:57:50 +08:00
|
|
|
// If they have the same way of getting the pc value (e.g. "CFA - 8" + "CFA is
|
2018-05-01 00:49:04 +08:00
|
|
|
// sp"), then it will return LazyBoolTrue.
|
2016-09-07 04:57:50 +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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
RegisterNumber pc_reg(thread, eRegisterKindGeneric, LLDB_REGNUM_GENERIC_PC);
|
|
|
|
uint32_t pc_reg_lldb_regnum = pc_reg.GetAsKind(eRegisterKindLLDB);
|
|
|
|
|
|
|
|
if (a.get() && b.get()) {
|
|
|
|
UnwindPlan::RowSP a_first_row = a->GetRowAtIndex(0);
|
|
|
|
UnwindPlan::RowSP b_first_row = b->GetRowAtIndex(0);
|
|
|
|
|
|
|
|
if (a_first_row.get() && b_first_row.get()) {
|
|
|
|
UnwindPlan::Row::RegisterLocation a_pc_regloc;
|
|
|
|
UnwindPlan::Row::RegisterLocation b_pc_regloc;
|
|
|
|
|
|
|
|
a_first_row->GetRegisterInfo(pc_reg_lldb_regnum, a_pc_regloc);
|
|
|
|
b_first_row->GetRegisterInfo(pc_reg_lldb_regnum, b_pc_regloc);
|
2016-07-07 07:06:19 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
plans_are_identical = eLazyBoolYes;
|
|
|
|
|
|
|
|
if (a_first_row->GetCFAValue() != b_first_row->GetCFAValue()) {
|
|
|
|
plans_are_identical = eLazyBoolNo;
|
|
|
|
}
|
|
|
|
if (a_pc_regloc != b_pc_regloc) {
|
|
|
|
plans_are_identical = eLazyBoolNo;
|
|
|
|
}
|
2016-07-07 07:06:19 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return plans_are_identical;
|
|
|
|
}
|
2016-07-07 07:06:19 +08:00
|
|
|
|
2016-09-07 04:57:50 +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);
|
2016-09-07 04:57:50 +08:00
|
|
|
UnwindPlanSP arch_default_at_entry_sp =
|
|
|
|
GetUnwindPlanArchitectureDefaultAtFunctionEntry(thread);
|
|
|
|
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
|
|
|
//
|
|
|
|
// 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
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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 = GetEHFrameAugmentedUnwindPlan(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;
|
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;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
return assembly_sp;
|
2010-09-10 15:49:16 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +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);
|
2016-09-07 04:57:50 +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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
m_tried_unwind_fast = true;
|
|
|
|
|
|
|
|
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);
|
2016-09-07 04:57:50 +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
|
|
|
}
|
|
|
|
return m_unwind_plan_fast_sp;
|
|
|
|
}
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
UnwindPlanSP FuncUnwinders::GetUnwindPlanArchitectureDefault(Thread &thread) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2016-09-07 04:57:50 +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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
m_tried_unwind_arch_default = true;
|
|
|
|
|
|
|
|
Address current_pc;
|
|
|
|
ProcessSP process_sp(thread.CalculateProcess());
|
|
|
|
if (process_sp) {
|
|
|
|
ABI *abi = process_sp->GetABI().get();
|
|
|
|
if (abi) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_arch_default_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2016-09-07 04:57:50 +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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return m_unwind_plan_arch_default_sp;
|
2011-09-15 08:44:34 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
UnwindPlanSP
|
|
|
|
FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry(Thread &thread) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (m_unwind_plan_arch_default_at_func_entry_sp.get() ||
|
|
|
|
m_tried_unwind_arch_default_at_func_entry)
|
|
|
|
return m_unwind_plan_arch_default_at_func_entry_sp;
|
|
|
|
|
|
|
|
m_tried_unwind_arch_default_at_func_entry = true;
|
|
|
|
|
|
|
|
Address current_pc;
|
|
|
|
ProcessSP process_sp(thread.CalculateProcess());
|
|
|
|
if (process_sp) {
|
|
|
|
ABI *abi = process_sp->GetABI().get();
|
|
|
|
if (abi) {
|
2019-02-12 07:13:08 +08:00
|
|
|
m_unwind_plan_arch_default_at_func_entry_sp =
|
|
|
|
std::make_shared<UnwindPlan>(lldb::eRegisterKindGeneric);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!abi->CreateFunctionEntryUnwindPlan(
|
|
|
|
*m_unwind_plan_arch_default_at_func_entry_sp)) {
|
|
|
|
m_unwind_plan_arch_default_at_func_entry_sp.reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-09-15 08:44:34 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return m_unwind_plan_arch_default_at_func_entry_sp;
|
|
|
|
}
|
2014-12-21 18:44:54 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Address &FuncUnwinders::GetFirstNonPrologueInsn(Target &target) {
|
2017-02-24 11:35:46 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2016-09-07 04:57:50 +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
|
|
|
|
|
|
|
ExecutionContext exe_ctx(target.shared_from_this(), false);
|
|
|
|
UnwindAssemblySP assembly_profiler_sp(GetUnwindAssemblyProfiler(target));
|
|
|
|
if (assembly_profiler_sp)
|
|
|
|
assembly_profiler_sp->FirstNonPrologueInsn(m_range, exe_ctx,
|
|
|
|
m_first_non_prologue_insn);
|
|
|
|
return m_first_non_prologue_insn;
|
2010-09-10 15:49:16 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const Address &FuncUnwinders::GetFunctionStartAddress() const {
|
|
|
|
return m_range.GetBaseAddress();
|
2010-09-10 15:49:16 +08:00
|
|
|
}
|
|
|
|
|
2014-05-23 09:48:10 +08:00
|
|
|
lldb::UnwindAssemblySP
|
2016-09-07 04:57:50 +08:00
|
|
|
FuncUnwinders::GetUnwindAssemblyProfiler(Target &target) {
|
|
|
|
UnwindAssemblySP assembly_profiler_sp;
|
2019-01-03 18:37:19 +08:00
|
|
|
if (ArchSpec arch = m_unwind_table.GetArchitecture()) {
|
2016-09-07 04:57:50 +08:00
|
|
|
arch.MergeFrom(target.GetArchitecture());
|
|
|
|
assembly_profiler_sp = UnwindAssembly::FindPlugin(arch);
|
|
|
|
}
|
|
|
|
return assembly_profiler_sp;
|
2014-05-23 09:48:10 +08:00
|
|
|
}
|
2014-11-18 10:27:42 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Address FuncUnwinders::GetLSDAAddress(Target &target) {
|
|
|
|
Address lsda_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);
|
2016-09-07 04:57:50 +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);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
if (unwind_plan_sp.get() && unwind_plan_sp->GetLSDAAddress().IsValid()) {
|
|
|
|
lsda_addr = unwind_plan_sp->GetLSDAAddress();
|
|
|
|
}
|
|
|
|
return lsda_addr;
|
2014-11-18 10:27:42 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Address FuncUnwinders::GetPersonalityRoutinePtrAddress(Target &target) {
|
|
|
|
Address personality_addr;
|
2014-11-18 10:27:42 +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);
|
2016-09-07 04:57:50 +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);
|
2016-09-07 04:57:50 +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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return personality_addr;
|
2014-11-18 10:27:42 +08:00
|
|
|
}
|