[llvm] Use value_or instead of getValueOr (NFC)

Exposes interface to free up caching data structure in DWARFDebugLine and DWARFUnit for memory management

This is minimum changes extracted from https://reviews.llvm.org/D78950. The old patch tried

Exposes interface to free up caching data structure in DWARFDebugLine and DWARFUnit for memory management

This is minimum changes extracted from https://reviews.llvm.org/D78950. The old patch tried to add LRU eviction of caching data structure. Due to multiple layers of interfaces that users could be using, it was not clear where to put the functionality. While we work out on where to put that functionality, it'll be great to add this minimum interface change so that the user could implement their own memory management. More specifically:

* Add a clearLineTable method for DWARFDebugLine which erases the given offset from the LineTableMap.
* DWARFDebugContext adds the clearLineTableForUnit method that leverages clearLineTable to remove the object corresponding to a given compile unit, for memory management purposes. When it is referred to again, the line table object will be repopulated.

Reviewed By: dblaikie

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

show more ...

[symbolizer] Parse DW_TAG_variable DIs to show line info for globals

Currently, llvm-symbolizer doesn't like to parse .debug_info in order to
show the line info for global variables. addr2line does

[symbolizer] Parse DW_TAG_variable DIs to show line info for globals

Currently, llvm-symbolizer doesn't like to parse .debug_info in order to
show the line info for global variables. addr2line does this. In the
future, I'm looking to migrate AddressSanitizer off of internal metadata
over to using debuginfo, and this is predicated on being able to get the
line info for global variables.

This patch adds the requisite support for getting the line info from the
.debug_info section for symbolizing global variables. This only happens
when you ask for a global variable to be symbolized as data.

Reviewed By: dblaikie

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

show more ...

DebugInfo: Use hash-based unit lookup when available in dwp files

Fix a test case that had a bogus (probably I hand crafted it at some
point) index that didn't point to the right data in the process.

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 ...

Fix a typo (occured => occurred)

Reported:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005195

Use Optional::getValueOr (NFC)

DebugInfo: Sink string form validation down from verifier to form parsing

Avoid duplicating the string decoding - improve the error messages down
in form parsing (& produce an Expected<const char*>

DebugInfo: Sink string form validation down from verifier to form parsing

Avoid duplicating the string decoding - improve the error messages down
in form parsing (& produce an Expected<const char*> instead of
Optional<const char*> to communicate the extra error details)

show more ...

[DebugInfo] Expand ability to load 2-byte addresses in dwarf sections

Some dwarf loaders in LLVM are hard-coded to only accept 4-byte and 8-byte address sizes. This patch generalizes acceptance into

[DebugInfo] Expand ability to load 2-byte addresses in dwarf sections

Some dwarf loaders in LLVM are hard-coded to only accept 4-byte and 8-byte address sizes. This patch generalizes acceptance into `DWARFContext::isAddressSizeSupported` and provides a common way to generate rejection errors.

The MSP430 target has been given new tests to cover dwarf loading cases that previously failed due to 2-byte addresses.

Reviewed By: dblaikie

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

show more ...

[DWARF][NFC] add ParentIdx and SiblingIdx to DWARFDebugInfoEntry for faster navigation.

This patch implements suggestion done while reviewing D102634. It adds two fields:
ParentIdx and SiblingIdx. T

[DWARF][NFC] add ParentIdx and SiblingIdx to DWARFDebugInfoEntry for faster navigation.

This patch implements suggestion done while reviewing D102634. It adds two fields:
ParentIdx and SiblingIdx. These fields allow fast navigation to die parent and
die sibling. These fields are set at the moment when dies are loaded.

dsymutil works 2% faster with this patch(run on clang binary).

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

show more ...

[DebugInfo][NFC] Erase capacity in DWARFUnit::clearDIEs().

DWARFUnit::clearDIEs() uses std::vector::shrink_to_fit() to make
capacity of DieArray matched with its size(). The shrink_to_fit()
is not b

[DebugInfo][NFC] Erase capacity in DWARFUnit::clearDIEs().

DWARFUnit::clearDIEs() uses std::vector::shrink_to_fit() to make
capacity of DieArray matched with its size(). The shrink_to_fit()
is not binding request to make capacity match with size().
Thus the memory could still be reserved after DWARFUnit::clearDIEs()
is called. This patch erases capacity when DWARFUnit::clearDIEs() is requested.
So the memory occupied by dies would be freed.

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

show more ...

[DWARF] Remove parseListTableHeader (NFC)

The last use was removed on Oct 4, 2020 in commit
6d0be74af5555f7bc56ac72cbd98ff270fd1291b.

DebugInfo: Use debug_rnglists.dwo for ranges in debug_info.dwo when parsing DWARFv5

This call would incorrectly overwrite (with the .debug_rnglists.dwo from
the executable, if there was one) the rng

DebugInfo: Use debug_rnglists.dwo for ranges in debug_info.dwo when parsing DWARFv5

This call would incorrectly overwrite (with the .debug_rnglists.dwo from
the executable, if there was one) the rnglists section instead of the
correct value (from the .debug_rnglists.dwo in the .dwo file) that's
applied in DWARFUnit::tryExtractDIEsIfNeeded

show more ...

Reapply "llvm-symbolizer: Fix "start file" to work with Split DWARF"

Originally committed as 04c203e310bd3fb58e16c936c0200d680100526e
Reverted in 768510632c5ddbf9438693d9c7db1903e39295ad due to the

Reapply "llvm-symbolizer: Fix "start file" to work with Split DWARF"

Originally committed as 04c203e310bd3fb58e16c936c0200d680100526e
Reverted in 768510632c5ddbf9438693d9c7db1903e39295ad due to the test
failing when encountering windows directory separators.

Fix the path separator platform issue with a FileCheck pattern {{[/\\]}}

Original commit message:

A followup to the feature added in 69da27c7496ea373567ce5121e6fe8613846e7a5
that added the optional "start file name" to match "start line" - but this
didn't work with Split DWARF because of the need for the decl file number
resolution code to refer back to the skeleton unit to find its .debug_line
contribution. So this patch adds the necessary infrastructure to track the
skeleton unit corresponding to a split full unit for the purpose of this
lookup.

show more ...

Revert "llvm-symbolizer: Fix "start file" to work with Split DWARF"

This reverts commit 04c203e310bd3fb58e16c936c0200d680100526e.
Test fails on Windows.

llvm-symbolizer: Fix "start file" to work with Split DWARF

A followup to the feature added in
69da27c7496ea373567ce5121e6fe8613846e7a5 that added the optional "start
file name" to match "start line"

llvm-symbolizer: Fix "start file" to work with Split DWARF

A followup to the feature added in
69da27c7496ea373567ce5121e6fe8613846e7a5 that added the optional "start
file name" to match "start line" - but this didn't work with Split DWARF
because of the need for the decl file number resolution code to refer
back to the skeleton unit to find its .debug_line contribution. So this
patch adds the necessary infrastructure to track the skeleton unit
corresponding to a split full unit for the purpose of this lookup.

show more ...

llvm-dwarfdump: Print warnings on invalid DWARF

llvm-dwarfdump was silent even when the format of DWARF was invalid
and/or llvm-dwarfdump did not understand/support some of the constructs.
This can

llvm-dwarfdump: Print warnings on invalid DWARF

llvm-dwarfdump was silent even when the format of DWARF was invalid
and/or llvm-dwarfdump did not understand/support some of the constructs.
This can be pretty confusing as llvm-dwarfdump is a tool for DWARF
producers+consumers development.

Review comments also by @dblaikie.

Reviewed By: jhenderson

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

show more ...

[DWARF] Check for AddrOffsetSectionBase to work with DWO Units.

Context: https://lists.llvm.org/pipermail/llvm-dev/2021-February/148521.html

A fix for llvm-symbolizer, and other tools like BOLT, th

[DWARF] Check for AddrOffsetSectionBase to work with DWO Units.

Context: https://lists.llvm.org/pipermail/llvm-dev/2021-February/148521.html

A fix for llvm-symbolizer, and other tools like BOLT, that allows retrieving address when built with -gsplit-dwarf=single mode.

Reviewed By: dblaikie

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

show more ...

Fix a crash in DWARFUnit::getInlinedChainForAddress in case of unexpected DWARF information.

In some cases a broken or invalid debug info could cause a crash in DWARFUnit::getInlinedChainForAddress

Fix a crash in DWARFUnit::getInlinedChainForAddress in case of unexpected DWARF information.

In some cases a broken or invalid debug info could cause a crash in DWARFUnit::getInlinedChainForAddress during parsing a chain of in-lined functions. This patch fixes this issue.

Reviewed By: dblaikie

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

show more ...

[llvm] Use hasSingleElement (NFC)

libDebugInfoDWARF: Don't try to parse loclist[.dwo] headers when parsing debug_info[.dwo]

There's no way to know whether there's a loclist contribution to parse
if there's no loclistx encoding - and

libDebugInfoDWARF: Don't try to parse loclist[.dwo] headers when parsing debug_info[.dwo]

There's no way to know whether there's a loclist contribution to parse
if there's no loclistx encoding - and if there is one, there's no need
to walk back from the loclist_base (or, uin the case of
info.dwo/loclist.dwo - starting at 0 in the contribution) to parse the
header, instead rely on the DWARF32/64 and address size in the CU
that's already available.

This would come up in split DWARF (non-split wouldn't try to read a
loclist header in the absence of a loclist_base) when one unit had
location lists and another does not (because the loclists.dwo section
would be non-empty in that case - in the case where it's empty the
parsing would silently skip).

Simplify the testing a bit, rather than needing a whole dwp, etc - by
creating a malformed loclists.dwo section (and use single file Split
DWARF) that would trip up any attempt to parse it - but no attempt
should be made.

show more ...

llvm-dwarfdump: Don't try to parse rnglist tables when dumping CUs

It's not possible to do this in complete generality - a CU using a
sec_offset DW_AT_ranges has no way of knowing where its rnglists

llvm-dwarfdump: Don't try to parse rnglist tables when dumping CUs

It's not possible to do this in complete generality - a CU using a
sec_offset DW_AT_ranges has no way of knowing where its rnglists
contribution starts, so should not attempt to parse any full rnglist
table/header to do so. And even using FORM_rnglistx there's no need to
parse the header - the offset can be computed using the CU's DWARF
format (32 or 64) to compute offset entry sizes, and then the list
parsed at that offset without ever trying to find a rnglist contribution
header immediately prior to the rnglists_base.

show more ...

[WIP][DebugInfo] Lazily parse debug_loclist offsets

Parsing DWARFv5 debug_loclist offsets when a CU is parsed is weighing
down memory usage of symbolizers that don't need to parse this data at
all.

[WIP][DebugInfo] Lazily parse debug_loclist offsets

Parsing DWARFv5 debug_loclist offsets when a CU is parsed is weighing
down memory usage of symbolizers that don't need to parse this data at
all. There's not much benefit to caching these anyway - since they are
O(1) lookup and reading once you know where the offset list starts (and
can do bounds checking with the offset list size too).

In general, I think it might be time to start paying down some of the
technical debt of loc/loclist/range/rnglist parsing to try to unify it a
bit more.

eg:

* Currently DWARFUnit has: RangeSection, RangeSectionBase, LocSection,
LocSectionBase, LocTable, RngListTable, LoclistTableHeader (be nice if
these were all wrapped up in two variables - one for loclists, one for
rnglists)

* rnglists and loclists are handled differently (see:
LoclistTableHeader, but no RnglistTableHeader)

* maybe all these types could be less stateful - lazily parse what they
need to, even reparsing rather than caching because it doesn't seem
too expensive, for instance. (though admittedly so long as it's
constantcost/overead per compilatiton that's probably adequate)

* Maybe implementing and using a DWARFDataExtractor that can be
sub-ranged (so we could slice it up to just the single contribution) -
though maybe that's not so useful because loc/ranges need to refer to
it by absolute, not contribution-relative mechanisms

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

show more ...

[DebugInfo] Avoid an infinite loop with a truncated pre-v5 .debug_str_offsets.dwo.

dumpStringOffsetsSection() expects the size of a contribution to be
correctly aligned. The patch adds the correspon

[DebugInfo] Avoid an infinite loop with a truncated pre-v5 .debug_str_offsets.dwo.

dumpStringOffsetsSection() expects the size of a contribution to be
correctly aligned. The patch adds the corresponding verifications for
pre-v5 cases.

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

show more ...

[DebugInfo] Explicitly permit addr_size = 0x02 when parsing DWARF data

Current LLVM implementation uses `MCAsmInfo::CodePointerSize` as addr_size when emitting the DWARF data. llvm-dwarfdump, on the

[DebugInfo] Explicitly permit addr_size = 0x02 when parsing DWARF data

Current LLVM implementation uses `MCAsmInfo::CodePointerSize` as addr_size when emitting the DWARF data. llvm-dwarfdump, on the other hand, handles `addr_size`s of 4 and 8 properly and considers all other sizes as an error. This works for most of mainline targets except for MSP430 and AVR.

msp430-gcc v8.3.1 emits DWARF32 with addr_size = 4 (DWARF32 does not imply addr_size = 4, 32 refers to internal offset width of 4 bytes) that is handled by llvm-dwarfdump already. Still, emitting 2-byte target pointers on MSP430 seems correct as well (but not for MSP430X that is supported by msp430-gcc but not by LLVM and has 20-bit address space).

This patch make it possible for MSP430 debug info support to be tested with llvm-dwarfdump.

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

show more ...