[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
|
|
|
//===-- ManualDWARFIndex.cpp ----------------------------------------------===//
|
2018-05-21 22:12:52 +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
|
2018-05-21 22:12:52 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "Plugins/SymbolFile/DWARF/ManualDWARFIndex.h"
|
2018-05-24 20:12:49 +08:00
|
|
|
#include "Plugins/Language/ObjC/ObjCLanguage.h"
|
2018-05-21 22:12:52 +08:00
|
|
|
#include "Plugins/SymbolFile/DWARF/DWARFDebugInfo.h"
|
|
|
|
#include "Plugins/SymbolFile/DWARF/DWARFDeclContext.h"
|
2018-05-24 20:12:49 +08:00
|
|
|
#include "Plugins/SymbolFile/DWARF/LogChannelDWARF.h"
|
|
|
|
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h"
|
2018-05-21 22:12:52 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Host/TaskPool.h"
|
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
#include "lldb/Utility/Stream.h"
|
|
|
|
#include "lldb/Utility/Timer.h"
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
using namespace lldb;
|
|
|
|
|
|
|
|
void ManualDWARFIndex::Index() {
|
|
|
|
if (!m_debug_info)
|
|
|
|
return;
|
|
|
|
|
|
|
|
DWARFDebugInfo &debug_info = *m_debug_info;
|
|
|
|
m_debug_info = nullptr;
|
|
|
|
|
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, "%p", static_cast<void *>(&debug_info));
|
|
|
|
|
2018-06-07 18:35:28 +08:00
|
|
|
std::vector<DWARFUnit *> units_to_index;
|
2019-05-11 01:14:37 +08:00
|
|
|
units_to_index.reserve(debug_info.GetNumUnits());
|
|
|
|
for (size_t U = 0; U < debug_info.GetNumUnits(); ++U) {
|
|
|
|
DWARFUnit *unit = debug_info.GetUnitAtIndex(U);
|
2018-06-07 18:35:28 +08:00
|
|
|
if (unit && m_units_to_avoid.count(unit->GetOffset()) == 0)
|
|
|
|
units_to_index.push_back(unit);
|
|
|
|
}
|
|
|
|
if (units_to_index.empty())
|
2018-05-21 22:12:52 +08:00
|
|
|
return;
|
|
|
|
|
2018-06-07 18:35:28 +08:00
|
|
|
std::vector<IndexSet> sets(units_to_index.size());
|
2018-05-21 22:12:52 +08:00
|
|
|
|
2019-05-11 01:14:37 +08:00
|
|
|
// Keep memory down by clearing DIEs for any units if indexing
|
|
|
|
// caused us to load the unit's DIEs.
|
2018-06-07 18:35:28 +08:00
|
|
|
std::vector<llvm::Optional<DWARFUnit::ScopedExtractDIEs>> clear_cu_dies(
|
|
|
|
units_to_index.size());
|
2018-05-21 22:12:52 +08:00
|
|
|
auto parser_fn = [&](size_t cu_idx) {
|
2018-06-07 18:35:28 +08:00
|
|
|
IndexUnit(*units_to_index[cu_idx], sets[cu_idx]);
|
2018-05-21 22:12:52 +08:00
|
|
|
};
|
|
|
|
|
2018-06-07 18:35:28 +08:00
|
|
|
auto extract_fn = [&units_to_index, &clear_cu_dies](size_t cu_idx) {
|
|
|
|
clear_cu_dies[cu_idx] = units_to_index[cu_idx]->ExtractDIEsScoped();
|
2018-05-21 22:12:52 +08:00
|
|
|
};
|
|
|
|
|
2019-05-11 01:14:37 +08:00
|
|
|
// Create a task runner that extracts dies for each DWARF unit in a
|
2018-05-21 22:12:52 +08:00
|
|
|
// separate thread
|
2019-05-11 01:14:37 +08:00
|
|
|
// First figure out which units didn't have their DIEs already
|
2018-05-21 22:12:52 +08:00
|
|
|
// parsed and remember this. If no DIEs were parsed prior to this index
|
|
|
|
// function call, we are going to want to clear the CU dies after we are
|
|
|
|
// done indexing to make sure we don't pull in all DWARF dies, but we need
|
2019-05-11 01:14:37 +08:00
|
|
|
// to wait until all units have been indexed in case a DIE in one
|
|
|
|
// unit refers to another and the indexes accesses those DIEs.
|
2018-06-07 18:35:28 +08:00
|
|
|
TaskMapOverInt(0, units_to_index.size(), extract_fn);
|
2018-05-21 22:12:52 +08:00
|
|
|
|
2019-05-11 01:14:37 +08:00
|
|
|
// Now create a task runner that can index each DWARF unit in a
|
2018-05-21 22:12:52 +08:00
|
|
|
// separate thread so we can index quickly.
|
|
|
|
|
2018-06-07 18:35:28 +08:00
|
|
|
TaskMapOverInt(0, units_to_index.size(), parser_fn);
|
2018-05-21 22:12:52 +08:00
|
|
|
|
2018-05-25 17:55:51 +08:00
|
|
|
auto finalize_fn = [this, &sets](NameToDIE(IndexSet::*index)) {
|
|
|
|
NameToDIE &result = m_set.*index;
|
|
|
|
for (auto &set : sets)
|
|
|
|
result.Append(set.*index);
|
|
|
|
result.Finalize();
|
2018-05-21 22:12:52 +08:00
|
|
|
};
|
|
|
|
|
2018-05-25 17:55:51 +08:00
|
|
|
TaskPool::RunTasks([&]() { finalize_fn(&IndexSet::function_basenames); },
|
|
|
|
[&]() { finalize_fn(&IndexSet::function_fullnames); },
|
|
|
|
[&]() { finalize_fn(&IndexSet::function_methods); },
|
|
|
|
[&]() { finalize_fn(&IndexSet::function_selectors); },
|
|
|
|
[&]() { finalize_fn(&IndexSet::objc_class_selectors); },
|
|
|
|
[&]() { finalize_fn(&IndexSet::globals); },
|
|
|
|
[&]() { finalize_fn(&IndexSet::types); },
|
|
|
|
[&]() { finalize_fn(&IndexSet::namespaces); });
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
2018-05-25 17:55:51 +08:00
|
|
|
void ManualDWARFIndex::IndexUnit(DWARFUnit &unit, IndexSet &set) {
|
2019-06-14 21:01:16 +08:00
|
|
|
assert(
|
[lldb/DWARF] Don't assume that a SymbolFileDWARFDwo contains one compile unit
Summary:
This is a preparatory patch to re-enable DWP support in lldb (we already
have code claiming to do that, but it has been completely broken for a
while now).
The idea of the new approach is to make the SymbolFileDWARFDwo class
handle both dwo and dwo files, similar to how llvm uses one DWARFContext
to handle the two.
The first step is to remove the assumption that a SymbolFileDWARFDwo
holds just a single compile unit, i.e. the GetBaseCompileUnit method.
This requires changing the way how we reach the skeleton compile unit
(and the lldb_private::CompileUnit) from a dwo unit, which was
previously done via GetSymbolFile()->GetBaseCompileUnit() (and some
virtual dispatch).
The new approach reuses the "user data" mechanism of DWARFUnits, which
was used to link dwarf units (both skeleton and split) to their
lldb_private counterparts. Now, this is done only for non-dwo units, and
instead of that, the dwo units holds a pointer to the relevant skeleton
unit.
Reviewers: JDevlieghere, aprantl, clayborg
Reviewed By: JDevlieghere, clayborg
Subscribers: arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73781
2020-02-06 11:45:22 +08:00
|
|
|
!unit.IsDWOUnit() &&
|
2019-04-04 17:24:02 +08:00
|
|
|
"DWARFUnit associated with .dwo or .dwp should not be indexed directly");
|
|
|
|
|
2018-05-24 20:12:49 +08:00
|
|
|
Log *log = LogChannelDWARF::GetLogIfAll(DWARF_LOG_LOOKUPS);
|
|
|
|
|
|
|
|
if (log) {
|
|
|
|
m_module.LogMessage(
|
2019-05-11 01:14:37 +08:00
|
|
|
log, "ManualDWARFIndex::IndexUnit for unit at .debug_info[0x%8.8x]",
|
2018-05-24 20:12:49 +08:00
|
|
|
unit.GetOffset());
|
|
|
|
}
|
|
|
|
|
2020-01-31 22:16:31 +08:00
|
|
|
const LanguageType cu_language = SymbolFileDWARF::GetLanguage(unit);
|
2018-05-24 20:12:49 +08:00
|
|
|
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
IndexUnitImpl(unit, cu_language, set);
|
2018-05-24 20:12:49 +08:00
|
|
|
|
DWARF: Add support for type units+split dwarf combo
Summary:
With the last round of refactors, supporting type units in dwo files
becomes almost trivial. This patch contains a couple of small fixes,
which taken as a whole make type units work in the split dwarf scenario
(both DWARF4 and DWARF5):
- DWARFContext: make sure we actually read the debug_types.dwo section
- DWARFUnit: set string offsets base on all units in the dwo file, not
just the main CU
- ManualDWARFIndex: index all units in the file
- SymbolFileDWARFDwo: Search for the single compile unit in the file, as
we can no longer assume it will be the first one
The last part makes it obvious that there is still some work to be done
here, namely that we do not support dwo files with multiple compile
units. That is something that should be easier after the DIERef
refactors, but it still requires more work.
Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as
well as a test that checks we behave reasonably in the presence of dwo
files with multiple CUs.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63643
llvm-svn: 364274
2019-06-25 14:59:48 +08:00
|
|
|
if (SymbolFileDWARFDwo *dwo_symbol_file = unit.GetDwoSymbolFile()) {
|
|
|
|
DWARFDebugInfo &dwo_info = *dwo_symbol_file->DebugInfo();
|
|
|
|
for (size_t i = 0; i < dwo_info.GetNumUnits(); ++i)
|
|
|
|
IndexUnitImpl(*dwo_info.GetUnitAtIndex(i), cu_language, set);
|
2018-05-24 20:12:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
void ManualDWARFIndex::IndexUnitImpl(DWARFUnit &unit,
|
|
|
|
const LanguageType cu_language,
|
|
|
|
IndexSet &set) {
|
2018-05-24 20:12:49 +08:00
|
|
|
for (const DWARFDebugInfoEntry &die : unit.dies()) {
|
|
|
|
const dw_tag_t tag = die.Tag();
|
|
|
|
|
|
|
|
switch (tag) {
|
|
|
|
case DW_TAG_array_type:
|
|
|
|
case DW_TAG_base_type:
|
|
|
|
case DW_TAG_class_type:
|
|
|
|
case DW_TAG_constant:
|
|
|
|
case DW_TAG_enumeration_type:
|
|
|
|
case DW_TAG_inlined_subroutine:
|
|
|
|
case DW_TAG_namespace:
|
|
|
|
case DW_TAG_string_type:
|
|
|
|
case DW_TAG_structure_type:
|
|
|
|
case DW_TAG_subprogram:
|
|
|
|
case DW_TAG_subroutine_type:
|
|
|
|
case DW_TAG_typedef:
|
|
|
|
case DW_TAG_union_type:
|
|
|
|
case DW_TAG_unspecified_type:
|
|
|
|
case DW_TAG_variable:
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
DWARFAttributes attributes;
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
const char *name = nullptr;
|
|
|
|
const char *mangled_cstr = nullptr;
|
2018-05-24 20:12:49 +08:00
|
|
|
bool is_declaration = false;
|
|
|
|
// bool is_artificial = false;
|
|
|
|
bool has_address = false;
|
|
|
|
bool has_location_or_const_value = false;
|
|
|
|
bool is_global_or_static_variable = false;
|
|
|
|
|
|
|
|
DWARFFormValue specification_die_form;
|
2019-05-25 06:08:50 +08:00
|
|
|
const size_t num_attributes = die.GetAttributes(&unit, attributes);
|
2018-05-24 20:12:49 +08:00
|
|
|
if (num_attributes > 0) {
|
|
|
|
for (uint32_t i = 0; i < num_attributes; ++i) {
|
|
|
|
dw_attr_t attr = attributes.AttributeAtIndex(i);
|
|
|
|
DWARFFormValue form_value;
|
|
|
|
switch (attr) {
|
|
|
|
case DW_AT_name:
|
|
|
|
if (attributes.ExtractFormValueAtIndex(i, form_value))
|
|
|
|
name = form_value.AsCString();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_AT_declaration:
|
|
|
|
if (attributes.ExtractFormValueAtIndex(i, form_value))
|
|
|
|
is_declaration = form_value.Unsigned() != 0;
|
|
|
|
break;
|
|
|
|
|
|
|
|
// case DW_AT_artificial:
|
|
|
|
// if (attributes.ExtractFormValueAtIndex(i,
|
|
|
|
// form_value))
|
|
|
|
// is_artificial = form_value.Unsigned() != 0;
|
|
|
|
// break;
|
|
|
|
|
|
|
|
case DW_AT_MIPS_linkage_name:
|
|
|
|
case DW_AT_linkage_name:
|
|
|
|
if (attributes.ExtractFormValueAtIndex(i, form_value))
|
|
|
|
mangled_cstr = form_value.AsCString();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_AT_low_pc:
|
|
|
|
case DW_AT_high_pc:
|
|
|
|
case DW_AT_ranges:
|
|
|
|
has_address = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_AT_entry_pc:
|
|
|
|
has_address = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_AT_location:
|
|
|
|
case DW_AT_const_value:
|
|
|
|
has_location_or_const_value = true;
|
|
|
|
if (tag == DW_TAG_variable) {
|
|
|
|
const DWARFDebugInfoEntry *parent_die = die.GetParent();
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
while (parent_die != nullptr) {
|
2018-05-24 20:12:49 +08:00
|
|
|
switch (parent_die->Tag()) {
|
|
|
|
case DW_TAG_subprogram:
|
|
|
|
case DW_TAG_lexical_block:
|
|
|
|
case DW_TAG_inlined_subroutine:
|
|
|
|
// Even if this is a function level static, we don't add it. We
|
|
|
|
// could theoretically add these if we wanted to by
|
|
|
|
// introspecting into the DW_AT_location and seeing if the
|
|
|
|
// location describes a hard coded address, but we don't want
|
|
|
|
// the performance penalty of that right now.
|
|
|
|
is_global_or_static_variable = false;
|
|
|
|
// if (attributes.ExtractFormValueAtIndex(dwarf, i,
|
|
|
|
// form_value)) {
|
|
|
|
// // If we have valid block data, then we have location
|
|
|
|
// // expression bytesthat are fixed (not a location list).
|
|
|
|
// const uint8_t *block_data = form_value.BlockData();
|
|
|
|
// if (block_data) {
|
|
|
|
// uint32_t block_length = form_value.Unsigned();
|
|
|
|
// if (block_length == 1 +
|
2019-05-11 01:14:37 +08:00
|
|
|
// attributes.UnitAtIndex(i)->GetAddressByteSize()) {
|
2018-05-24 20:12:49 +08:00
|
|
|
// if (block_data[0] == DW_OP_addr)
|
|
|
|
// add_die = true;
|
|
|
|
// }
|
|
|
|
// }
|
|
|
|
// }
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
parent_die = nullptr; // Terminate the while loop.
|
2018-05-24 20:12:49 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_TAG_compile_unit:
|
|
|
|
case DW_TAG_partial_unit:
|
|
|
|
is_global_or_static_variable = true;
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
parent_die = nullptr; // Terminate the while loop.
|
2018-05-24 20:12:49 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
parent_die =
|
|
|
|
parent_die->GetParent(); // Keep going in the while loop.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_AT_specification:
|
|
|
|
if (attributes.ExtractFormValueAtIndex(i, form_value))
|
|
|
|
specification_die_form = form_value;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
DIERef ref = *DWARFDIE(&unit, &die).GetDIERef();
|
2018-05-24 20:12:49 +08:00
|
|
|
switch (tag) {
|
2018-05-29 16:16:22 +08:00
|
|
|
case DW_TAG_inlined_subroutine:
|
2018-05-24 20:12:49 +08:00
|
|
|
case DW_TAG_subprogram:
|
|
|
|
if (has_address) {
|
|
|
|
if (name) {
|
2019-06-15 03:18:10 +08:00
|
|
|
bool is_objc_method = false;
|
|
|
|
if (cu_language == eLanguageTypeObjC ||
|
|
|
|
cu_language == eLanguageTypeObjC_plus_plus) {
|
|
|
|
ObjCLanguage::MethodName objc_method(name, true);
|
|
|
|
if (objc_method.IsValid(true)) {
|
|
|
|
is_objc_method = true;
|
|
|
|
ConstString class_name_with_category(
|
|
|
|
objc_method.GetClassNameWithCategory());
|
|
|
|
ConstString objc_selector_name(objc_method.GetSelector());
|
|
|
|
ConstString objc_fullname_no_category_name(
|
|
|
|
objc_method.GetFullNameWithoutCategory(true));
|
|
|
|
ConstString class_name_no_category(objc_method.GetClassName());
|
|
|
|
set.function_fullnames.Insert(ConstString(name), ref);
|
|
|
|
if (class_name_with_category)
|
|
|
|
set.objc_class_selectors.Insert(class_name_with_category, ref);
|
|
|
|
if (class_name_no_category &&
|
|
|
|
class_name_no_category != class_name_with_category)
|
|
|
|
set.objc_class_selectors.Insert(class_name_no_category, ref);
|
|
|
|
if (objc_selector_name)
|
|
|
|
set.function_selectors.Insert(objc_selector_name, ref);
|
|
|
|
if (objc_fullname_no_category_name)
|
|
|
|
set.function_fullnames.Insert(objc_fullname_no_category_name,
|
2019-05-14 20:44:40 +08:00
|
|
|
ref);
|
2019-06-15 03:18:10 +08:00
|
|
|
}
|
2018-05-24 20:12:49 +08:00
|
|
|
}
|
|
|
|
// If we have a mangled name, then the DW_AT_name attribute is
|
|
|
|
// usually the method name without the class or any parameters
|
2018-06-04 17:05:27 +08:00
|
|
|
bool is_method = DWARFDIE(&unit, &die).IsMethod();
|
2018-05-24 20:12:49 +08:00
|
|
|
|
|
|
|
if (is_method)
|
2019-05-14 20:44:40 +08:00
|
|
|
set.function_methods.Insert(ConstString(name), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
else
|
2019-05-14 20:44:40 +08:00
|
|
|
set.function_basenames.Insert(ConstString(name), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
|
2019-06-15 03:18:10 +08:00
|
|
|
if (!is_method && !mangled_cstr && !is_objc_method)
|
2019-05-14 20:44:40 +08:00
|
|
|
set.function_fullnames.Insert(ConstString(name), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
}
|
|
|
|
if (mangled_cstr) {
|
|
|
|
// Make sure our mangled name isn't the same string table entry as
|
|
|
|
// our name. If it starts with '_', then it is ok, else compare the
|
|
|
|
// string to make sure it isn't the same and we don't end up with
|
|
|
|
// duplicate entries
|
|
|
|
if (name && name != mangled_cstr &&
|
|
|
|
((mangled_cstr[0] == '_') ||
|
|
|
|
(::strcmp(name, mangled_cstr) != 0))) {
|
2019-05-14 20:44:40 +08:00
|
|
|
set.function_fullnames.Insert(ConstString(mangled_cstr), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_TAG_array_type:
|
|
|
|
case DW_TAG_base_type:
|
|
|
|
case DW_TAG_class_type:
|
|
|
|
case DW_TAG_constant:
|
|
|
|
case DW_TAG_enumeration_type:
|
|
|
|
case DW_TAG_string_type:
|
|
|
|
case DW_TAG_structure_type:
|
|
|
|
case DW_TAG_subroutine_type:
|
|
|
|
case DW_TAG_typedef:
|
|
|
|
case DW_TAG_union_type:
|
|
|
|
case DW_TAG_unspecified_type:
|
|
|
|
if (name && !is_declaration)
|
2019-05-14 20:44:40 +08:00
|
|
|
set.types.Insert(ConstString(name), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
if (mangled_cstr && !is_declaration)
|
2019-05-14 20:44:40 +08:00
|
|
|
set.types.Insert(ConstString(mangled_cstr), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_TAG_namespace:
|
|
|
|
if (name)
|
2019-05-14 20:44:40 +08:00
|
|
|
set.namespaces.Insert(ConstString(name), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case DW_TAG_variable:
|
|
|
|
if (name && has_location_or_const_value && is_global_or_static_variable) {
|
2019-05-14 20:44:40 +08:00
|
|
|
set.globals.Insert(ConstString(name), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
// Be sure to include variables by their mangled and demangled names if
|
|
|
|
// they have any since a variable can have a basename "i", a mangled
|
|
|
|
// named "_ZN12_GLOBAL__N_11iE" and a demangled mangled name
|
|
|
|
// "(anonymous namespace)::i"...
|
|
|
|
|
|
|
|
// Make sure our mangled name isn't the same string table entry as our
|
|
|
|
// name. If it starts with '_', then it is ok, else compare the string
|
|
|
|
// to make sure it isn't the same and we don't end up with duplicate
|
|
|
|
// entries
|
|
|
|
if (mangled_cstr && name != mangled_cstr &&
|
|
|
|
((mangled_cstr[0] == '_') || (::strcmp(name, mangled_cstr) != 0))) {
|
2019-05-14 20:44:40 +08:00
|
|
|
set.globals.Insert(ConstString(mangled_cstr), ref);
|
2018-05-24 20:12:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-07 18:04:44 +08:00
|
|
|
void ManualDWARFIndex::GetGlobalVariables(ConstString basename, DIEArray &offsets) {
|
2018-05-21 22:12:52 +08:00
|
|
|
Index();
|
2018-06-07 18:04:44 +08:00
|
|
|
m_set.globals.Find(basename, offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ManualDWARFIndex::GetGlobalVariables(const RegularExpression ®ex,
|
|
|
|
DIEArray &offsets) {
|
|
|
|
Index();
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.globals.Find(regex, offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
void ManualDWARFIndex::GetGlobalVariables(const DWARFUnit &unit,
|
2018-05-21 22:12:52 +08:00
|
|
|
DIEArray &offsets) {
|
|
|
|
Index();
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
m_set.globals.FindAllEntriesForUnit(unit, offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ManualDWARFIndex::GetObjCMethods(ConstString class_name,
|
|
|
|
DIEArray &offsets) {
|
|
|
|
Index();
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.objc_class_selectors.Find(class_name, offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ManualDWARFIndex::GetCompleteObjCClass(ConstString class_name,
|
|
|
|
bool must_be_implementation,
|
|
|
|
DIEArray &offsets) {
|
|
|
|
Index();
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.types.Find(class_name, offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ManualDWARFIndex::GetTypes(ConstString name, DIEArray &offsets) {
|
|
|
|
Index();
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.types.Find(name, offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ManualDWARFIndex::GetTypes(const DWARFDeclContext &context,
|
|
|
|
DIEArray &offsets) {
|
|
|
|
Index();
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.types.Find(ConstString(context[0].name), offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ManualDWARFIndex::GetNamespaces(ConstString name, DIEArray &offsets) {
|
|
|
|
Index();
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.namespaces.Find(name, offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
void ManualDWARFIndex::GetFunctions(ConstString name, SymbolFileDWARF &dwarf,
|
2018-06-05 18:33:56 +08:00
|
|
|
const CompilerDeclContext &parent_decl_ctx,
|
|
|
|
uint32_t name_type_mask,
|
|
|
|
std::vector<DWARFDIE> &dies) {
|
2018-05-21 22:12:52 +08:00
|
|
|
Index();
|
|
|
|
|
|
|
|
if (name_type_mask & eFunctionNameTypeFull) {
|
2018-06-05 18:33:56 +08:00
|
|
|
DIEArray offsets;
|
|
|
|
m_set.function_fullnames.Find(name, offsets);
|
|
|
|
for (const DIERef &die_ref: offsets) {
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
DWARFDIE die = dwarf.GetDIE(die_ref);
|
2018-06-05 18:33:56 +08:00
|
|
|
if (!die)
|
|
|
|
continue;
|
|
|
|
if (SymbolFileDWARF::DIEInDeclContext(&parent_decl_ctx, die))
|
|
|
|
dies.push_back(die);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (name_type_mask & eFunctionNameTypeBase) {
|
2018-06-05 18:33:56 +08:00
|
|
|
DIEArray offsets;
|
|
|
|
m_set.function_basenames.Find(name, offsets);
|
|
|
|
for (const DIERef &die_ref: offsets) {
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
DWARFDIE die = dwarf.GetDIE(die_ref);
|
2018-06-05 18:33:56 +08:00
|
|
|
if (!die)
|
|
|
|
continue;
|
|
|
|
if (SymbolFileDWARF::DIEInDeclContext(&parent_decl_ctx, die))
|
|
|
|
dies.push_back(die);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
offsets.clear();
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:33:56 +08:00
|
|
|
if (name_type_mask & eFunctionNameTypeMethod && !parent_decl_ctx.IsValid()) {
|
|
|
|
DIEArray offsets;
|
|
|
|
m_set.function_methods.Find(name, offsets);
|
|
|
|
for (const DIERef &die_ref: offsets) {
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
if (DWARFDIE die = dwarf.GetDIE(die_ref))
|
2018-06-05 18:33:56 +08:00
|
|
|
dies.push_back(die);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:33:56 +08:00
|
|
|
if (name_type_mask & eFunctionNameTypeSelector &&
|
|
|
|
!parent_decl_ctx.IsValid()) {
|
|
|
|
DIEArray offsets;
|
|
|
|
m_set.function_selectors.Find(name, offsets);
|
|
|
|
for (const DIERef &die_ref: offsets) {
|
DWARF: Add "dwo_num" field to the DIERef class
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
2019-06-21 15:56:50 +08:00
|
|
|
if (DWARFDIE die = dwarf.GetDIE(die_ref))
|
2018-06-05 18:33:56 +08:00
|
|
|
dies.push_back(die);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-05 20:13:22 +08:00
|
|
|
void ManualDWARFIndex::GetFunctions(const RegularExpression ®ex,
|
|
|
|
DIEArray &offsets) {
|
2018-05-21 22:12:52 +08:00
|
|
|
Index();
|
|
|
|
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.function_basenames.Find(regex, offsets);
|
|
|
|
m_set.function_fullnames.Find(regex, offsets);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ManualDWARFIndex::Dump(Stream &s) {
|
2018-06-06 19:35:23 +08:00
|
|
|
s.Format("Manual DWARF index for ({0}) '{1:F}':",
|
2018-05-21 22:12:52 +08:00
|
|
|
m_module.GetArchitecture().GetArchitectureName(),
|
|
|
|
m_module.GetObjectFile()->GetFileSpec());
|
|
|
|
s.Printf("\nFunction basenames:\n");
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.function_basenames.Dump(&s);
|
2018-05-21 22:12:52 +08:00
|
|
|
s.Printf("\nFunction fullnames:\n");
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.function_fullnames.Dump(&s);
|
2018-05-21 22:12:52 +08:00
|
|
|
s.Printf("\nFunction methods:\n");
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.function_methods.Dump(&s);
|
2018-05-21 22:12:52 +08:00
|
|
|
s.Printf("\nFunction selectors:\n");
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.function_selectors.Dump(&s);
|
2018-06-14 00:21:24 +08:00
|
|
|
s.Printf("\nObjective-C class selectors:\n");
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.objc_class_selectors.Dump(&s);
|
2018-05-21 22:12:52 +08:00
|
|
|
s.Printf("\nGlobals and statics:\n");
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.globals.Dump(&s);
|
2018-05-21 22:12:52 +08:00
|
|
|
s.Printf("\nTypes:\n");
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.types.Dump(&s);
|
2018-05-21 22:12:52 +08:00
|
|
|
s.Printf("\nNamespaces:\n");
|
2018-05-25 17:55:51 +08:00
|
|
|
m_set.namespaces.Dump(&s);
|
2018-05-21 22:12:52 +08:00
|
|
|
}
|