Cleanup LLVMDWARFDebugInfo

As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/DebugInfo/DWARF/DWARFContext.h no longer includes:
- "llvm/DebugInfo/DW

Cleanup LLVMDWARFDebugInfo

As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/DebugInfo/DWARF/DWARFContext.h no longer includes:
- "llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h"
- "llvm/DebugInfo/DWARF/DWARFCompileUnit.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAbbrev.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAranges.h"
- "llvm/DebugInfo/DWARF/DWARFDebugFrame.h"
- "llvm/DebugInfo/DWARF/DWARFDebugLoc.h"
- "llvm/DebugInfo/DWARF/DWARFDebugMacro.h"
- "llvm/DebugInfo/DWARF/DWARFGdbIndex.h"
- "llvm/DebugInfo/DWARF/DWARFSection.h"
- "llvm/DebugInfo/DWARF/DWARFTypeUnit.h"
- "llvm/DebugInfo/DWARF/DWARFUnitIndex.h"

Plus llvm/Support/Errc.h not included by a bunch of llvm/DebugInfo/DWARF/DWARF*.h files

Preprocessed lines to build llvm on my setup:
after: 1065629059
before: 1066621848

Which is a great diff!

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119723

show more ...

[DebugInfo] DWARF - Use const-ref iterator in for-range loop. NFCI.

Avoid unnecessary copies, reported by MSVC static analyzer.

[DebugInfo] Report the format of .debug_names [2/10]

Differential Revision: https://reviews.llvm.org/D80523

[DWARF] Use DWARFDataExtractor::getInitialLength to parse debug_names

Summary:
In this patch I've done a slightly bigger rewrite to also remove the
hardcoded header lengths.

Reviewers: jhenderson,

[DWARF] Use DWARFDataExtractor::getInitialLength to parse debug_names

Summary:
In this patch I've done a slightly bigger rewrite to also remove the
hardcoded header lengths.

Reviewers: jhenderson, dblaikie, ikudrin

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75119

show more ...

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...

Remove redundant "std::move"s in return statements

[DWARF] Add support for 64-bit DWARF in .debug_names.

Differential Revision: https://reviews.llvm.org/D72900

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

[DWARF] Eliminate the DWARFDebugNames::Header::Padding field.

The padding field is reserved for DWARF and does not contain any useful
information. No need to read, store and report it.

Differential

[DWARF] Eliminate the DWARFDebugNames::Header::Padding field.

The padding field is reserved for DWARF and does not contain any useful
information. No need to read, store and report it.

Differential Revision: https://reviews.llvm.org/D73042

show more ...

[DWARF] Get rid of DWARFDebugNames::HeaderPOD. NFC.

This structure was used to get the size of the fixed-size part of a Name
Index header for 32-bit DWARF. It is unsuitable for 64-bit DWARF because

[DWARF] Get rid of DWARFDebugNames::HeaderPOD. NFC.

This structure was used to get the size of the fixed-size part of a Name
Index header for 32-bit DWARF. It is unsuitable for 64-bit DWARF because
the size of the unit length field is different.

Differential Revision: https://reviews.llvm.org/D73040

show more ...

[NFC] Fixes -Wrange-loop-analysis warnings

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

Differential Revision: https://reviews.llvm.org/D71857

Remove support for 32-bit offsets in utility classes (5/5)

Differential Revision: https://reviews.llvm.org/D65641

llvm-svn: 368156

Try to unbreak buildbots after r368014

llvm-svn: 368018

Switch LLVM to use 64-bit offsets (2/5)

This updates all libraries and tools in LLVM Core to use 64-bit offsets
which directly or indirectly come to DataExtractor.

Differential Revision: https://re

Switch LLVM to use 64-bit offsets (2/5)

This updates all libraries and tools in LLVM Core to use 64-bit offsets
which directly or indirectly come to DataExtractor.

Differential Revision: https://reviews.llvm.org/D65638

llvm-svn: 368014

show more ...

[DWARF] Fix dump of local/foreign TU lists in .debug_names

Differential Revision: https://reviews.llvm.org/D61241

llvm-svn: 359425

[DWARF] llvm::Error -> Error. NFC

The unqualified name is more common and is used in the file as well.

llvm-svn: 358567

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[DWARF] Refactor DWARF classes to use unified error reporting. NFC.

DWARF-related classes in lib/DebugInfo/DWARF contained
duplicating code for creating StringError instances, like:

template <type

[DWARF] Refactor DWARF classes to use unified error reporting. NFC.

DWARF-related classes in lib/DebugInfo/DWARF contained
duplicating code for creating StringError instances, like:

template <typename... Ts>
static Error createError(char const *Fmt, const Ts &... Vals) {
std::string Buffer;
raw_string_ostream Stream(Buffer);
Stream << format(Fmt, Vals...);
return make_error<StringError>(Stream.str(), inconvertibleErrorCode());
}

Similar function was placed in Support lib in https://reviews.llvm.org/D49824

This revision makes DWARF classes use this function
instead of their local implementation of it.

Reviewers: aprantl, dblaikie, probinson, wolfgangp, JDevlieghere, jhenderson

Reviewed By: JDevlieghere, jhenderson

Differential Revision: https://reviews.llvm.org/D49964

llvm-svn: 340163

show more ...

[dwarfdump] Add pretty printer for accelerator table based on Atom.

For instance, When dumping .apple_types, the second atom represents the
DW_TAG. In addition to printing the raw value, we now also

[dwarfdump] Add pretty printer for accelerator table based on Atom.

For instance, When dumping .apple_types, the second atom represents the
DW_TAG. In addition to printing the raw value, we now also pretty print
the value if the ATOM tells us how.

llvm-svn: 337026

show more ...

[DWARF/AccelTable] Remove getDIESectionOffset for DWARF v5 entries

Summary:
This method was not correct for entries in DWO files as it assumed it
could just add up the CU and DIE offsets to get the

[DWARF/AccelTable] Remove getDIESectionOffset for DWARF v5 entries

Summary:
This method was not correct for entries in DWO files as it assumed it
could just add up the CU and DIE offsets to get the absolute DIE offset.
This is not correct for the DWO files, as here the CU offset will
reference the skeleton unit, whereas the DIE offset will be the offset
in the full unit in the DWO file.

Unfortunately, this means that we are not able to determine the absolute
DIE offset using the information in the .debug_names section alone,
which means we have to offload some of this work to the users of this
class.

To demonstrate how this can be done, I've added/fixed the ability to
lookup entries using accelerator tables in DWO files in llvm-dwarfdump.
To make this happen, I've needed to make two extra changes in other
classes:
- made the DWARFContext method to lookup a CU based on the section
offset public. I've needed this functionality to lookup a CU, and this
seems like a useful thing in general.
- made DWARFUnit::getDWOId call extractDIEsIfNeeded. Before this, the
DWOId was filled in only if the root DIE happened to be parsed
before we called the accessor. Since the lazy parsing is supposed to
happen under the hood, calling extractDIEsIfNeeded seems appropriate.

Reviewers: JDevlieghere, aprantl, dblaikie

Subscribers: mgrang, llvm-commits

Differential Revision: https://reviews.llvm.org/D48009

llvm-svn: 334578

show more ...

DWARFAcceleratorTable: Add an iterator-based api for accessing names in the index

Summary:
Back when we were introducing the DWARF v5 name index, there was a
short discussion whether we shouldn't ha

DWARFAcceleratorTable: Add an iterator-based api for accessing names in the index

Summary:
Back when we were introducing the DWARF v5 name index, there was a
short discussion whether we shouldn't have a nicer api for iterating
over the index. At that time, I did not find it necessary since the
iteration over names was done only from within the index itself (and I
figured the internal implementation can deal with a slightly rough
interface).

However, now I ran into a use for this kind of API in LLDB (for finding
all names matching a regular expression), so it looked like a nice
opportunity to introduce one. To make the API more useful, I've made the
NameTableEntry class a bit smarter: it now stores the string section
reference (so it can return its name) and its position in the name index
(mainly useful for dumping/logging).

I also convert the internal users to use the new API, which also gives
test coverage for the added code.

Reviewers: JDevlieghere, aprantl, dblaikie

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D47590

llvm-svn: 333738

show more ...

DWARFAcceleratorTable: fix equal_range iterators

Summary:
Both (Apple and DWARF5) implementations of the iterators had bugs which
resulted in crashes if one attempted to iterate through the accelera

DWARFAcceleratorTable: fix equal_range iterators

Summary:
Both (Apple and DWARF5) implementations of the iterators had bugs which
resulted in crashes if one attempted to iterate through the accelerator
tables all the way.

For the Apple tables, the issue was that we did not clear the DataOffset
field when we reached the end, which made our iterator compare unequal
to the "end" iterator. For the Dwarf5 tables, the problem was that we
incremented the CurrentIndex pointer and then used the incremented
(possibly invalid) pointer to check whether we have reached the end of
the index list.

The reason these bugs went undetected is because their only user
(dwarfdump) only ever searched for the first match. Besides allowing us
to test this fix, changing llvm-dwarfdump --find to display all matches
seems like a good improvement (it makes the behavior consistent with the
--name option), so I change llvm-dwarfdump to do that.

The existing tests would be sufficient to test this fix with the new
llvm-dwarfdump behavior, but I add a special test that demonstrates that
the tool indeed displays multiple results. The find.test test needed to
be tweaked a bit as the tool now does not print the ".debug_info
contents" header (also consistent with how --name works).

Reviewers: JDevlieghere, aprantl, dblaikie

Subscribers: mgrang, llvm-commits

Differential Revision: https://reviews.llvm.org/D47543

llvm-svn: 333635

show more ...

Reapply "DWARFVerifier: Check "completeness" of .debug_names section"

This is a resubmit of r331868 (D46583), which was reverted due to
failures on the PS4 bot.

These have been resolved with r33224

Reapply "DWARFVerifier: Check "completeness" of .debug_names section"

This is a resubmit of r331868 (D46583), which was reverted due to
failures on the PS4 bot.

These have been resolved with r332246/D46748.

llvm-svn: 332349

show more ...

Revert "DWARFVerifier: Check "completeness" of .debug_names section"

The new verifier check has found an error in the
debug-names-name-collisions.ll test on the PS4 bot:

error: Name Index @ 0x0: En

Revert "DWARFVerifier: Check "completeness" of .debug_names section"

The new verifier check has found an error in the
debug-names-name-collisions.ll test on the PS4 bot:

error: Name Index @ 0x0: Entry @ 0xdc: mismatched Name of DIE @ 0x23: index - _ZN3foo3fooE; debug_info - foo.

Reverting while I investigate whether this is a bug in the verifier or
the generator.

This reverts commit r331868.

llvm-svn: 331869

show more ...

DWARFVerifier: Check "completeness" of .debug_names section

Summary:
This patch implements a check which makes sure all entries required by
the DWARF v5 specification are present in the Name Index.

DWARFVerifier: Check "completeness" of .debug_names section

Summary:
This patch implements a check which makes sure all entries required by
the DWARF v5 specification are present in the Name Index. The algorithm
tries to follow the wording of Section 6.1.1.1 of the spec as closely as
possible.

The main deviation from it is that instead of a whitelist-based approach
in the spec "The name index must contain an entry for each debugging
information entry that defines a named subprogram, label, variable,
type, or namespace" I chose a blacklist-based one, where I consider
everything to be "in" and then remove the entries that don't make sense.
I did this because it has more potential for catching interesting cases
and the above is a bit vague (it uses plain words like "variable" and
"subprogram", but the rest of the section speaks about specific TAGs).

This approach has raised some interesting questions, the main one being
whether enumerator values should be indexed. The consensus seems to be
that they should, although it does not follow from section 6.1.1.1.
For the time being I made the verifier ignore these, as LLVM does not do
this yet, and I wanted to get a clean run when verifying generated debug
info.

Another interesting case was the DW_TAG_imported_declaration. It was not
immediately clear to me whether this should go in or not, but currently
it is not indexed, and (unlike the enumerators) in does not seem to cause
problems for LLDB, so I've also ignored it.

Reviewers: JDevlieghere, aprantl, dblaikie

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D46583

llvm-svn: 331868

show more ...