[llvm-dev] llvm-dwarfdump on whole-split-file fails to account for indirection through skeleton
via llvm-dev
llvm-dev at lists.llvm.org
Wed Oct 24 11:56:22 PDT 2018
If we do find that multiple skeletons are possible in the same .o, we can find the right one pretty cheaply by matching the dwo_id in the header.
--paulr
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev
Sent: Wednesday, October 24, 2018 2:34 PM
To: George Rimar; Pieb, Wolfgang; llvm-dev
Subject: [llvm-dev] llvm-dwarfdump on whole-split-file fails to account for indirection through skeleton
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/b5fb76a5/attachment.html>
More information about the llvm-dev
mailing list