[llvm-dev] llvm-dwarfdump on whole-split-file fails to account for indirection through skeleton

[David Blaikie via llvm-dev]

Hi folks,

Just a minor bug I probably won't get to but thought I should raise:

llvm-dwarfdump when run on an object file containing split-DWARF (so it has
both .debug_info, .debug_addr, etc, and .debug_info.dwo, etc) has some
minor quirks when it comes to DWARFv5 support.

The range-dumping functionality uses DWARFUnit::getAddrOffsetSectionItem on
the unit that contains the range attribute (DW_AT_ranges, etc) - so ranges
in the .dwo can still read addresses and use them to print the addresses in
the range list accounting for relocations and printing section names, etc.

Problem is that the split-unit doesn't have the DW_AT_addr_base attribute
(it's in the skeleton unit) so getAddrOffsetSectionItem reads from the
start of the section, instead of the start of the contribution (after the
header).

Would be good to fix that - especially if you're interested in supporting
non-split split-DWARF (.dwo sections in the object files, more like MachO
debug info).

Not sure what the right solution to that is - I mean, ultimately it means
having llvm-dwarfdump lookup the skeleton CU in the same object file.

I guess since this can only apply to the object file (the .dwo sections
won't be linked into the executable) - and split-DWARF doesn't support
multiple skeleton CUs in a single object file I think... (I remember trying
to figure that out with ThinLTO & my memory is a bit hazy) - so maybe it's
as simple as "if we're using debug_addr, make sure we're reading/using the
skeleton CU which should be the only unit in debug_info in this object".

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181024/d6824917/attachment.html>