[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 08:23:27 +01:00
|
|
|
//===-- UnwindTable.cpp ---------------------------------------------------===//
|
2010-09-10 07:49:16 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00: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 07:49:16 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2010-09-23 01:09:21 +00:00
|
|
|
#include "lldb/Symbol/UnwindTable.h"
|
2010-09-10 07:49:16 +00:00
|
|
|
|
2021-05-26 12:19:37 +02:00
|
|
|
#include <cstdio>
|
2023-01-07 13:43:00 -08:00
|
|
|
#include <optional>
|
2010-09-23 01:09:21 +00:00
|
|
|
|
|
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
|
#include "lldb/Core/Section.h"
|
2015-09-30 13:50:14 +00: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 09:03:29 +00:00
|
|
|
#include "lldb/Symbol/CallFrameInfo.h"
|
2014-12-08 03:09:00 +00:00
|
|
|
#include "lldb/Symbol/CompactUnwindInfo.h"
|
2010-09-10 07:49:16 +00:00
|
|
|
#include "lldb/Symbol/DWARFCallFrameInfo.h"
|
|
|
|
|
#include "lldb/Symbol/FuncUnwinders.h"
|
2010-09-23 01:09:21 +00:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
2010-09-10 07:49:16 +00: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 07:54:37 +00:00
|
|
|
#include "lldb/Symbol/SymbolVendor.h"
|
2010-09-10 07:49:16 +00:00
|
|
|
|
2018-04-30 16:49:04 +00: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 07:49:16 +00:00
|
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
2019-02-14 14:40:10 +00:00
|
|
|
UnwindTable::UnwindTable(Module &module)
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
: m_module(module), m_unwinds(), m_scanned_all_unwind_sources(false),
|
|
|
|
|
m_mutex(), m_object_file_unwind_up(), m_eh_frame_up(),
|
|
|
|
|
m_compact_unwind_up(), m_arm_unwind_up() {}
|
2010-09-10 07:49:16 +00:00
|
|
|
|
|
|
|
|
// We can't do some of this initialization when the ObjectFile is running its
|
2018-04-30 16:49:04 +00:00
|
|
|
// ctor; delay doing it until needed for something.
|
2011-01-08 00:05:12 +00:00
|
|
|
void UnwindTable::Initialize() {
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
if (m_scanned_all_unwind_sources)
|
2010-09-10 07:49:16 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-05-19 05:13:57 +00:00
|
|
|
std::lock_guard<std::mutex> guard(m_mutex);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
if (m_scanned_all_unwind_sources) // check again once we've acquired the lock
|
2019-02-14 14:40:10 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2024-03-27 09:25:46 -07:00
|
|
|
ObjectFile *object_file = m_module.GetObjectFile();
|
|
|
|
|
if (!object_file)
|
|
|
|
|
return;
|
|
|
|
|
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
m_scanned_all_unwind_sources = true;
|
|
|
|
|
|
2024-03-27 09:25:46 -07:00
|
|
|
if (!m_object_file_unwind_up)
|
|
|
|
|
m_object_file_unwind_up = object_file->CreateCallFrameInfo();
|
|
|
|
|
|
|
|
|
|
SectionList *sl = m_module.GetSectionList();
|
|
|
|
|
if (!sl)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
SectionSP sect = sl->FindSectionByType(eSectionTypeEHFrame, true);
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
if (!m_eh_frame_up && sect)
|
2024-03-27 09:25:46 -07:00
|
|
|
m_eh_frame_up = std::make_unique<DWARFCallFrameInfo>(
|
|
|
|
|
*object_file, sect, DWARFCallFrameInfo::EH);
|
|
|
|
|
|
|
|
|
|
sect = sl->FindSectionByType(eSectionTypeDWARFDebugFrame, true);
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
if (!m_debug_frame_up && sect)
|
2024-03-27 09:25:46 -07:00
|
|
|
m_debug_frame_up = std::make_unique<DWARFCallFrameInfo>(
|
|
|
|
|
*object_file, sect, DWARFCallFrameInfo::DWARF);
|
|
|
|
|
|
|
|
|
|
sect = sl->FindSectionByType(eSectionTypeCompactUnwind, true);
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
if (!m_compact_unwind_up && sect)
|
2024-03-27 09:25:46 -07:00
|
|
|
m_compact_unwind_up =
|
|
|
|
|
std::make_unique<CompactUnwindInfo>(*object_file, sect);
|
|
|
|
|
|
|
|
|
|
sect = sl->FindSectionByType(eSectionTypeARMexidx, true);
|
|
|
|
|
if (!m_arm_unwind_up && sect) {
|
|
|
|
|
SectionSP sect_extab = sl->FindSectionByType(eSectionTypeARMextab, true);
|
|
|
|
|
if (sect_extab.get()) {
|
|
|
|
|
m_arm_unwind_up =
|
|
|
|
|
std::make_unique<ArmUnwindInfo>(*object_file, sect, sect_extab);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
void UnwindTable::ModuleWasUpdated() {
|
|
|
|
|
std::lock_guard<std::mutex> guard(m_mutex);
|
|
|
|
|
m_scanned_all_unwind_sources = false;
|
2025-02-07 12:52:21 +01:00
|
|
|
m_unwinds.clear();
|
[lldb] Change Module to have a concrete UnwindTable, update (#101130)
Currently a Module has a std::optional<UnwindTable> which is created
when the UnwindTable is requested from outside the Module. The idea is
to delay its creation until the Module has an ObjectFile initialized,
which will have been done by the time we're doing an unwind.
However, Module::GetUnwindTable wasn't doing any locking, so it was
possible for two threads to ask for the UnwindTable for the first time,
one would be created and returned while another thread would create one,
destroy the first in the process of emplacing it. It was an uncommon
crash, but it was possible.
Grabbing the Module's mutex would be one way to address it, but when
loading ELF binaries, we start creating the SymbolTable on one thread
(ObjectFileELF) grabbing the Module's mutex, and then spin up worker
threads to parse the individual DWARF compilation units, which then try
to also get the UnwindTable and deadlock if they try to get the Module's
mutex.
This changes Module to have a concrete UnwindTable as an ivar, and when
it adds an ObjectFile or SymbolFileVendor, it will call the Update
method on it, which will re-evaluate which sections exist in the
ObjectFile/SymbolFile. UnwindTable used to have an Initialize method
which set all the sections, and an Update method which would set some of
them if they weren't set. I unified these with the Initialize method
taking a `force` option to re-initialize the section pointers even if
they had been done already before.
This is addressing a rare crash report we've received, and also a
failure Adrian spotted on the -fsanitize=address CI bot last week, it's
still uncommon with ASAN but it can happen with the standard testsuite.
rdar://128876433
2024-08-01 17:43:25 -07:00
|
|
|
}
|
|
|
|
|
|
2021-07-02 11:27:37 -07:00
|
|
|
UnwindTable::~UnwindTable() = default;
|
2010-09-10 07:49:16 +00:00
|
|
|
|
2025-03-27 12:51:20 +01:00
|
|
|
AddressRanges UnwindTable::GetAddressRanges(const Address &addr,
|
|
|
|
|
const SymbolContext &sc) {
|
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 11:16:26 +00:00
|
|
|
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 09:03:29 +00: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))
|
2025-03-27 12:51:20 +01:00
|
|
|
return {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 09:03:29 +00:00
|
|
|
|
2024-10-14 15:25:52 -07:00
|
|
|
// Check the symbol context
|
2025-03-27 12:51:20 +01:00
|
|
|
AddressRanges result;
|
|
|
|
|
for (size_t idx = 0;
|
|
|
|
|
sc.GetAddressRange(eSymbolContextFunction | eSymbolContextSymbol, idx,
|
|
|
|
|
false, range) &&
|
|
|
|
|
range.GetBaseAddress().IsValid();
|
|
|
|
|
++idx)
|
|
|
|
|
result.push_back(range);
|
|
|
|
|
if (!result.empty())
|
|
|
|
|
return result;
|
2024-10-14 15:25:52 -07: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 11:16:26 +00:00
|
|
|
// 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))
|
2025-03-27 12:51:20 +01:00
|
|
|
return {range};
|
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 11:16:26 +00:00
|
|
|
|
|
|
|
|
// Try debug_frame as well
|
|
|
|
|
if (m_debug_frame_up && m_debug_frame_up->GetAddressRange(addr, range))
|
2025-03-27 12:51:20 +01:00
|
|
|
return {range};
|
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 11:16:26 +00:00
|
|
|
|
2025-03-27 12:51:20 +01:00
|
|
|
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 11:16:26 +00:00
|
|
|
}
|
|
|
|
|
|
[lldb] Parse DWARF CFI for discontinuous functions (#137006)
This patch uses the previously build infrastructure to parse multiple
FDE entries into a single unwind plan. There is one catch though: we
parse only one FDE entry per unwind range. This is not fully correct
because lldb coalesces adjecant address ranges, which means that
something that originally looked like two separate address ranges (and
two FDE entries) may get merged into one because if the linker decides
to put the two ranges next to each other. In this case, we will ignore
the second FDE entry.
It would be more correct to try to parse another entry when the one we
found turns out to be short, but I'm not doing this (yet), because:
- this is how we've done things so far (although, monolithic functions
are unlikely to have more than one FDE entry)
- in cases where we don't have debug info or (full) symbol tables, we
can end up with "symbols" which appear to span many megabytes
(potentially, the whole module). If we tried to fill short FDE entries,
we could end up parsing the entire eh_frame section in a single go. In a
way, this would be more correct, but it would also probably be very
slow.
I haven't quite decided what to do about this case yet, though it's not
particularly likely to happen in the "production" cases as typically the
functions are split into two parts (hot/cold) instead of one part per
basic block.
2025-05-07 15:04:22 +02:00
|
|
|
static Address GetFunctionOrSymbolAddress(const Address &addr,
|
|
|
|
|
const SymbolContext &sc) {
|
|
|
|
|
if (Address result = sc.GetFunctionOrSymbolAddress(); result.IsValid())
|
|
|
|
|
return result;
|
|
|
|
|
return addr;
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-10 07:49:16 +00:00
|
|
|
FuncUnwindersSP
|
2012-07-12 00:20:07 +00:00
|
|
|
UnwindTable::GetFuncUnwindersContainingAddress(const Address &addr,
|
2025-02-07 12:52:21 +01:00
|
|
|
const SymbolContext &sc) {
|
2011-01-08 00:05:12 +00:00
|
|
|
Initialize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-05-19 05:13:57 +00:00
|
|
|
std::lock_guard<std::mutex> guard(m_mutex);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-01-08 00:05:12 +00:00
|
|
|
// There is an UnwindTable per object file, so we can safely use file handles
|
|
|
|
|
addr_t file_addr = addr.GetFileAddress();
|
[lldb] Parse DWARF CFI for discontinuous functions (#137006)
This patch uses the previously build infrastructure to parse multiple
FDE entries into a single unwind plan. There is one catch though: we
parse only one FDE entry per unwind range. This is not fully correct
because lldb coalesces adjecant address ranges, which means that
something that originally looked like two separate address ranges (and
two FDE entries) may get merged into one because if the linker decides
to put the two ranges next to each other. In this case, we will ignore
the second FDE entry.
It would be more correct to try to parse another entry when the one we
found turns out to be short, but I'm not doing this (yet), because:
- this is how we've done things so far (although, monolithic functions
are unlikely to have more than one FDE entry)
- in cases where we don't have debug info or (full) symbol tables, we
can end up with "symbols" which appear to span many megabytes
(potentially, the whole module). If we tried to fill short FDE entries,
we could end up parsing the entire eh_frame section in a single go. In a
way, this would be more correct, but it would also probably be very
slow.
I haven't quite decided what to do about this case yet, though it's not
particularly likely to happen in the "production" cases as typically the
functions are split into two parts (hot/cold) instead of one part per
basic block.
2025-05-07 15:04:22 +02:00
|
|
|
iterator insert_pos = m_unwinds.upper_bound(file_addr);
|
|
|
|
|
if (insert_pos != m_unwinds.begin()) {
|
|
|
|
|
auto pos = std::prev(insert_pos);
|
2011-01-08 00:05:12 +00:00
|
|
|
if (pos->second->ContainsAddress(addr))
|
|
|
|
|
return pos->second;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
[lldb] Parse DWARF CFI for discontinuous functions (#137006)
This patch uses the previously build infrastructure to parse multiple
FDE entries into a single unwind plan. There is one catch though: we
parse only one FDE entry per unwind range. This is not fully correct
because lldb coalesces adjecant address ranges, which means that
something that originally looked like two separate address ranges (and
two FDE entries) may get merged into one because if the linker decides
to put the two ranges next to each other. In this case, we will ignore
the second FDE entry.
It would be more correct to try to parse another entry when the one we
found turns out to be short, but I'm not doing this (yet), because:
- this is how we've done things so far (although, monolithic functions
are unlikely to have more than one FDE entry)
- in cases where we don't have debug info or (full) symbol tables, we
can end up with "symbols" which appear to span many megabytes
(potentially, the whole module). If we tried to fill short FDE entries,
we could end up parsing the entire eh_frame section in a single go. In a
way, this would be more correct, but it would also probably be very
slow.
I haven't quite decided what to do about this case yet, though it's not
particularly likely to happen in the "production" cases as typically the
functions are split into two parts (hot/cold) instead of one part per
basic block.
2025-05-07 15:04:22 +02:00
|
|
|
Address start_addr = GetFunctionOrSymbolAddress(addr, sc);
|
2025-03-27 12:51:20 +01:00
|
|
|
AddressRanges ranges = GetAddressRanges(addr, sc);
|
|
|
|
|
if (ranges.empty())
|
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 11:16:26 +00:00
|
|
|
return nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
[lldb] Parse DWARF CFI for discontinuous functions (#137006)
This patch uses the previously build infrastructure to parse multiple
FDE entries into a single unwind plan. There is one catch though: we
parse only one FDE entry per unwind range. This is not fully correct
because lldb coalesces adjecant address ranges, which means that
something that originally looked like two separate address ranges (and
two FDE entries) may get merged into one because if the linker decides
to put the two ranges next to each other. In this case, we will ignore
the second FDE entry.
It would be more correct to try to parse another entry when the one we
found turns out to be short, but I'm not doing this (yet), because:
- this is how we've done things so far (although, monolithic functions
are unlikely to have more than one FDE entry)
- in cases where we don't have debug info or (full) symbol tables, we
can end up with "symbols" which appear to span many megabytes
(potentially, the whole module). If we tried to fill short FDE entries,
we could end up parsing the entire eh_frame section in a single go. In a
way, this would be more correct, but it would also probably be very
slow.
I haven't quite decided what to do about this case yet, though it's not
particularly likely to happen in the "production" cases as typically the
functions are split into two parts (hot/cold) instead of one part per
basic block.
2025-05-07 15:04:22 +02:00
|
|
|
auto func_unwinder_sp =
|
|
|
|
|
std::make_shared<FuncUnwinders>(*this, start_addr, ranges);
|
2025-03-27 12:51:20 +01:00
|
|
|
for (const AddressRange &range : ranges)
|
|
|
|
|
m_unwinds.emplace_hint(insert_pos, range.GetBaseAddress().GetFileAddress(),
|
|
|
|
|
func_unwinder_sp);
|
2011-01-08 00:05:12 +00:00
|
|
|
return func_unwinder_sp;
|
|
|
|
|
}
|
|
|
|
|
|
2012-07-12 00:20:07 +00:00
|
|
|
// Ignore any existing FuncUnwinders for this function, create a new one and
|
2018-04-30 16:49:04 +00: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.
|
2023-05-04 18:19:15 -07:00
|
|
|
FuncUnwindersSP UnwindTable::GetUncachedFuncUnwindersContainingAddress(
|
|
|
|
|
const Address &addr, const SymbolContext &sc) {
|
2012-07-12 00:20:07 +00:00
|
|
|
Initialize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
[lldb] Parse DWARF CFI for discontinuous functions (#137006)
This patch uses the previously build infrastructure to parse multiple
FDE entries into a single unwind plan. There is one catch though: we
parse only one FDE entry per unwind range. This is not fully correct
because lldb coalesces adjecant address ranges, which means that
something that originally looked like two separate address ranges (and
two FDE entries) may get merged into one because if the linker decides
to put the two ranges next to each other. In this case, we will ignore
the second FDE entry.
It would be more correct to try to parse another entry when the one we
found turns out to be short, but I'm not doing this (yet), because:
- this is how we've done things so far (although, monolithic functions
are unlikely to have more than one FDE entry)
- in cases where we don't have debug info or (full) symbol tables, we
can end up with "symbols" which appear to span many megabytes
(potentially, the whole module). If we tried to fill short FDE entries,
we could end up parsing the entire eh_frame section in a single go. In a
way, this would be more correct, but it would also probably be very
slow.
I haven't quite decided what to do about this case yet, though it's not
particularly likely to happen in the "production" cases as typically the
functions are split into two parts (hot/cold) instead of one part per
basic block.
2025-05-07 15:04:22 +02:00
|
|
|
Address start_addr = GetFunctionOrSymbolAddress(addr, sc);
|
2025-03-27 12:51:20 +01:00
|
|
|
AddressRanges ranges = GetAddressRanges(addr, sc);
|
|
|
|
|
if (ranges.empty())
|
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 11:16:26 +00:00
|
|
|
return nullptr;
|
2012-07-12 00:20:07 +00:00
|
|
|
|
[lldb] Parse DWARF CFI for discontinuous functions (#137006)
This patch uses the previously build infrastructure to parse multiple
FDE entries into a single unwind plan. There is one catch though: we
parse only one FDE entry per unwind range. This is not fully correct
because lldb coalesces adjecant address ranges, which means that
something that originally looked like two separate address ranges (and
two FDE entries) may get merged into one because if the linker decides
to put the two ranges next to each other. In this case, we will ignore
the second FDE entry.
It would be more correct to try to parse another entry when the one we
found turns out to be short, but I'm not doing this (yet), because:
- this is how we've done things so far (although, monolithic functions
are unlikely to have more than one FDE entry)
- in cases where we don't have debug info or (full) symbol tables, we
can end up with "symbols" which appear to span many megabytes
(potentially, the whole module). If we tried to fill short FDE entries,
we could end up parsing the entire eh_frame section in a single go. In a
way, this would be more correct, but it would also probably be very
slow.
I haven't quite decided what to do about this case yet, though it's not
particularly likely to happen in the "production" cases as typically the
functions are split into two parts (hot/cold) instead of one part per
basic block.
2025-05-07 15:04:22 +02:00
|
|
|
return std::make_shared<FuncUnwinders>(*this, start_addr, std::move(ranges));
|
2012-07-12 00:20:07 +00:00
|
|
|
}
|
|
|
|
|
|
2011-01-08 00:05:12 +00:00
|
|
|
void UnwindTable::Dump(Stream &s) {
|
2016-05-19 05:13:57 +00:00
|
|
|
std::lock_guard<std::mutex> guard(m_mutex);
|
2019-02-14 14:40:10 +00:00
|
|
|
s.Format("UnwindTable for '{0}':\n", m_module.GetFileSpec());
|
2011-01-08 00:05:12 +00:00
|
|
|
const_iterator begin = m_unwinds.begin();
|
|
|
|
|
const_iterator end = m_unwinds.end();
|
|
|
|
|
for (const_iterator pos = begin; pos != end; ++pos) {
|
2012-11-29 21:49:15 +00:00
|
|
|
s.Printf("[%u] 0x%16.16" PRIx64 "\n", (unsigned)std::distance(begin, pos),
|
|
|
|
|
pos->first);
|
2011-01-08 00:05:12 +00:00
|
|
|
}
|
|
|
|
|
s.EOL();
|
2010-09-10 07:49:16 +00: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 09:03:29 +00:00
|
|
|
lldb_private::CallFrameInfo *UnwindTable::GetObjectFileUnwindInfo() {
|
|
|
|
|
Initialize();
|
|
|
|
|
return m_object_file_unwind_up.get();
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-10 07:49:16 +00:00
|
|
|
DWARFCallFrameInfo *UnwindTable::GetEHFrameInfo() {
|
2011-01-08 00:05:12 +00:00
|
|
|
Initialize();
|
2015-09-30 13:50:14 +00:00
|
|
|
return m_eh_frame_up.get();
|
2010-09-10 07:49:16 +00:00
|
|
|
}
|
2014-05-23 01:48:10 +00: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 11:16:26 +00:00
|
|
|
DWARFCallFrameInfo *UnwindTable::GetDebugFrameInfo() {
|
|
|
|
|
Initialize();
|
|
|
|
|
return m_debug_frame_up.get();
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-08 03:09:00 +00:00
|
|
|
CompactUnwindInfo *UnwindTable::GetCompactUnwindInfo() {
|
|
|
|
|
Initialize();
|
2015-09-30 13:50:14 +00:00
|
|
|
return m_compact_unwind_up.get();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ArmUnwindInfo *UnwindTable::GetArmUnwindInfo() {
|
|
|
|
|
Initialize();
|
|
|
|
|
return m_arm_unwind_up.get();
|
2014-12-08 03:09:00 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-02 08:16:35 +00: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 07:54:37 +00:00
|
|
|
|
2019-02-14 14:40:10 +00:00
|
|
|
ArchSpec UnwindTable::GetArchitecture() { return m_module.GetArchitecture(); }
|
2016-05-04 03:09:40 +00:00
|
|
|
|
|
|
|
|
bool UnwindTable::GetAllowAssemblyEmulationUnwindPlans() {
|
2019-02-14 14:40:10 +00:00
|
|
|
if (ObjectFile *object_file = m_module.GetObjectFile())
|
|
|
|
|
return object_file->AllowAssemblyEmulationUnwindPlans();
|
|
|
|
|
return false;
|
2016-05-04 03:09:40 +00:00
|
|
|
}
|