[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
|
|
|
//===-- UnwindTable.cpp ---------------------------------------------------===//
|
2010-09-10 15:49:16 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-09-10 15:49:16 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2010-09-23 09:09:21 +08:00
|
|
|
#include "lldb/Symbol/UnwindTable.h"
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2021-05-26 18:19:37 +08:00
|
|
|
#include <cstdio>
|
2010-09-23 09:09:21 +08:00
|
|
|
|
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Core/Section.h"
|
2015-09-30 21:50:14 +08:00
|
|
|
#include "lldb/Symbol/ArmUnwindInfo.h"
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
#include "lldb/Symbol/CallFrameInfo.h"
|
2014-12-08 11:09:00 +08:00
|
|
|
#include "lldb/Symbol/CompactUnwindInfo.h"
|
2010-09-10 15:49:16 +08:00
|
|
|
#include "lldb/Symbol/DWARFCallFrameInfo.h"
|
|
|
|
#include "lldb/Symbol/FuncUnwinders.h"
|
2010-09-23 09:09:21 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
2010-09-10 15:49:16 +08:00
|
|
|
#include "lldb/Symbol/SymbolContext.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/SymbolVendor.h"
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// There is one UnwindTable object per ObjectFile. It contains a list of Unwind
|
|
|
|
// objects -- one per function, populated lazily -- for the ObjectFile. Each
|
|
|
|
// Unwind object has multiple UnwindPlans for different scenarios.
|
2010-09-10 15:49:16 +08:00
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2019-02-14 22:40:10 +08:00
|
|
|
UnwindTable::UnwindTable(Module &module)
|
|
|
|
: m_module(module), m_unwinds(), m_initialized(false), m_mutex(),
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
m_object_file_unwind_up(), m_eh_frame_up(), m_compact_unwind_up(),
|
|
|
|
m_arm_unwind_up() {}
|
2010-09-10 15:49:16 +08:00
|
|
|
|
|
|
|
// We can't do some of this initialization when the ObjectFile is running its
|
2018-05-01 00:49:04 +08:00
|
|
|
// ctor; delay doing it until needed for something.
|
2010-09-10 15:49:16 +08:00
|
|
|
|
2011-01-08 08:05:12 +08:00
|
|
|
void UnwindTable::Initialize() {
|
2010-09-10 15:49:16 +08:00
|
|
|
if (m_initialized)
|
|
|
|
return;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-05-19 13:13:57 +08:00
|
|
|
std::lock_guard<std::mutex> guard(m_mutex);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-06-19 07:32:53 +08:00
|
|
|
if (m_initialized) // check again once we've acquired the lock
|
|
|
|
return;
|
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_initialized = true;
|
2019-02-14 22:40:10 +08:00
|
|
|
ObjectFile *object_file = m_module.GetObjectFile();
|
|
|
|
if (!object_file)
|
|
|
|
return;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
m_object_file_unwind_up = object_file->CreateCallFrameInfo();
|
|
|
|
|
2019-03-18 18:45:02 +08:00
|
|
|
SectionList *sl = m_module.GetSectionList();
|
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 (!sl)
|
|
|
|
return;
|
|
|
|
|
|
|
|
SectionSP sect = sl->FindSectionByType(eSectionTypeEHFrame, true);
|
|
|
|
if (sect.get()) {
|
2020-06-25 08:44:33 +08:00
|
|
|
m_eh_frame_up = std::make_unique<DWARFCallFrameInfo>(
|
|
|
|
*object_file, sect, DWARFCallFrameInfo::EH);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-09-10 15:49:16 +08:00
|
|
|
|
Add debug_frame section support
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
2017-06-27 19:16:26 +08:00
|
|
|
sect = sl->FindSectionByType(eSectionTypeDWARFDebugFrame, true);
|
|
|
|
if (sect) {
|
2020-06-25 08:44:33 +08:00
|
|
|
m_debug_frame_up = std::make_unique<DWARFCallFrameInfo>(
|
|
|
|
*object_file, sect, DWARFCallFrameInfo::DWARF);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
sect = sl->FindSectionByType(eSectionTypeCompactUnwind, true);
|
|
|
|
if (sect) {
|
2020-06-25 08:44:33 +08:00
|
|
|
m_compact_unwind_up =
|
|
|
|
std::make_unique<CompactUnwindInfo>(*object_file, sect);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
sect = sl->FindSectionByType(eSectionTypeARMexidx, true);
|
|
|
|
if (sect) {
|
|
|
|
SectionSP sect_extab = sl->FindSectionByType(eSectionTypeARMextab, true);
|
|
|
|
if (sect_extab.get()) {
|
2020-06-25 08:44:33 +08:00
|
|
|
m_arm_unwind_up =
|
|
|
|
std::make_unique<ArmUnwindInfo>(*object_file, sect, sect_extab);
|
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
|
|
|
}
|
|
|
|
}
|
2010-09-10 15:49:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
UnwindTable::~UnwindTable() {}
|
|
|
|
|
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
|
|
|
llvm::Optional<AddressRange> UnwindTable::GetAddressRange(const Address &addr,
|
|
|
|
SymbolContext &sc) {
|
|
|
|
AddressRange range;
|
|
|
|
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
// First check the unwind info from the object file plugin
|
|
|
|
if (m_object_file_unwind_up &&
|
|
|
|
m_object_file_unwind_up->GetAddressRange(addr, range))
|
|
|
|
return range;
|
|
|
|
|
|
|
|
// Check the symbol context
|
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 (sc.GetAddressRange(eSymbolContextFunction | eSymbolContextSymbol, 0,
|
|
|
|
false, range) &&
|
|
|
|
range.GetBaseAddress().IsValid())
|
|
|
|
return range;
|
|
|
|
|
|
|
|
// Does the eh_frame unwind info has a function bounds for this addr?
|
|
|
|
if (m_eh_frame_up && m_eh_frame_up->GetAddressRange(addr, range))
|
|
|
|
return range;
|
|
|
|
|
|
|
|
// Try debug_frame as well
|
|
|
|
if (m_debug_frame_up && m_debug_frame_up->GetAddressRange(addr, range))
|
|
|
|
return range;
|
|
|
|
|
|
|
|
return llvm::None;
|
|
|
|
}
|
|
|
|
|
2010-09-10 15:49:16 +08:00
|
|
|
FuncUnwindersSP
|
2012-07-12 08:20:07 +08:00
|
|
|
UnwindTable::GetFuncUnwindersContainingAddress(const Address &addr,
|
|
|
|
SymbolContext &sc) {
|
2011-01-08 08:05:12 +08:00
|
|
|
Initialize();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-05-19 13:13:57 +08:00
|
|
|
std::lock_guard<std::mutex> guard(m_mutex);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2011-01-08 08:05:12 +08:00
|
|
|
// There is an UnwindTable per object file, so we can safely use file handles
|
|
|
|
addr_t file_addr = addr.GetFileAddress();
|
|
|
|
iterator end = m_unwinds.end();
|
|
|
|
iterator insert_pos = end;
|
|
|
|
if (!m_unwinds.empty()) {
|
|
|
|
insert_pos = m_unwinds.lower_bound(file_addr);
|
|
|
|
iterator pos = insert_pos;
|
|
|
|
if ((pos == m_unwinds.end()) ||
|
|
|
|
(pos != m_unwinds.begin() &&
|
|
|
|
pos->second->GetFunctionStartAddress() != addr))
|
2016-09-07 04:57:50 +08:00
|
|
|
--pos;
|
|
|
|
|
2011-01-08 08:05:12 +08:00
|
|
|
if (pos->second->ContainsAddress(addr))
|
|
|
|
return pos->second;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
Add debug_frame section support
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
2017-06-27 19:16:26 +08:00
|
|
|
auto range_or = GetAddressRange(addr, sc);
|
|
|
|
if (!range_or)
|
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
Add debug_frame section support
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
2017-06-27 19:16:26 +08:00
|
|
|
FuncUnwindersSP func_unwinder_sp(new FuncUnwinders(*this, *range_or));
|
2011-01-08 08:05:12 +08:00
|
|
|
m_unwinds.insert(insert_pos,
|
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::make_pair(range_or->GetBaseAddress().GetFileAddress(),
|
2011-01-08 08:05:12 +08:00
|
|
|
func_unwinder_sp));
|
|
|
|
return func_unwinder_sp;
|
|
|
|
}
|
|
|
|
|
2012-07-12 08:20:07 +08:00
|
|
|
// Ignore any existing FuncUnwinders for this function, create a new one and
|
2018-05-01 00:49:04 +08:00
|
|
|
// don't add it to the UnwindTable. This is intended for use by target modules
|
|
|
|
// show-unwind where we want to create new UnwindPlans, not re-use existing
|
|
|
|
// ones.
|
2012-07-12 08:20:07 +08:00
|
|
|
FuncUnwindersSP
|
|
|
|
UnwindTable::GetUncachedFuncUnwindersContainingAddress(const Address &addr,
|
|
|
|
SymbolContext &sc) {
|
|
|
|
Initialize();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
Add debug_frame section support
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
2017-06-27 19:16:26 +08:00
|
|
|
auto range_or = GetAddressRange(addr, sc);
|
|
|
|
if (!range_or)
|
|
|
|
return nullptr;
|
2012-07-12 08:20:07 +08:00
|
|
|
|
Add debug_frame section support
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
2017-06-27 19:16:26 +08:00
|
|
|
return std::make_shared<FuncUnwinders>(*this, *range_or);
|
2012-07-12 08:20:07 +08:00
|
|
|
}
|
|
|
|
|
2011-01-08 08:05:12 +08:00
|
|
|
void UnwindTable::Dump(Stream &s) {
|
2016-05-19 13:13:57 +08:00
|
|
|
std::lock_guard<std::mutex> guard(m_mutex);
|
2019-02-14 22:40:10 +08:00
|
|
|
s.Format("UnwindTable for '{0}':\n", m_module.GetFileSpec());
|
2011-01-08 08:05:12 +08:00
|
|
|
const_iterator begin = m_unwinds.begin();
|
|
|
|
const_iterator end = m_unwinds.end();
|
|
|
|
for (const_iterator pos = begin; pos != end; ++pos) {
|
2012-11-30 05:49:15 +08:00
|
|
|
s.Printf("[%u] 0x%16.16" PRIx64 "\n", (unsigned)std::distance(begin, pos),
|
|
|
|
pos->first);
|
2011-01-08 08:05:12 +08:00
|
|
|
}
|
|
|
|
s.EOL();
|
2010-09-10 15:49:16 +08:00
|
|
|
}
|
|
|
|
|
[Windows] Use information from the PE32 exceptions directory to construct unwind plans
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
2019-10-11 17:03:29 +08:00
|
|
|
lldb_private::CallFrameInfo *UnwindTable::GetObjectFileUnwindInfo() {
|
|
|
|
Initialize();
|
|
|
|
return m_object_file_unwind_up.get();
|
|
|
|
}
|
|
|
|
|
2010-09-10 15:49:16 +08:00
|
|
|
DWARFCallFrameInfo *UnwindTable::GetEHFrameInfo() {
|
2011-01-08 08:05:12 +08:00
|
|
|
Initialize();
|
2015-09-30 21:50:14 +08:00
|
|
|
return m_eh_frame_up.get();
|
2010-09-10 15:49:16 +08:00
|
|
|
}
|
2014-05-23 09:48:10 +08:00
|
|
|
|
Add debug_frame section support
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
2017-06-27 19:16:26 +08:00
|
|
|
DWARFCallFrameInfo *UnwindTable::GetDebugFrameInfo() {
|
|
|
|
Initialize();
|
|
|
|
return m_debug_frame_up.get();
|
|
|
|
}
|
|
|
|
|
2014-12-08 11:09:00 +08:00
|
|
|
CompactUnwindInfo *UnwindTable::GetCompactUnwindInfo() {
|
|
|
|
Initialize();
|
2015-09-30 21:50:14 +08:00
|
|
|
return m_compact_unwind_up.get();
|
|
|
|
}
|
|
|
|
|
|
|
|
ArmUnwindInfo *UnwindTable::GetArmUnwindInfo() {
|
|
|
|
Initialize();
|
|
|
|
return m_arm_unwind_up.get();
|
2014-12-08 11:09:00 +08:00
|
|
|
}
|
|
|
|
|
2019-08-02 16:16:35 +08:00
|
|
|
SymbolFile *UnwindTable::GetSymbolFile() { return m_module.GetSymbolFile(); }
|
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
|
|
|
|
2019-02-14 22:40:10 +08:00
|
|
|
ArchSpec UnwindTable::GetArchitecture() { return m_module.GetArchitecture(); }
|
2016-05-04 11:09:40 +08:00
|
|
|
|
|
|
|
bool UnwindTable::GetAllowAssemblyEmulationUnwindPlans() {
|
2019-02-14 22:40:10 +08:00
|
|
|
if (ObjectFile *object_file = m_module.GetObjectFile())
|
|
|
|
return object_file->AllowAssemblyEmulationUnwindPlans();
|
|
|
|
return false;
|
2016-05-04 11:09:40 +08:00
|
|
|
}
|