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

[via llvm-dev]

I don’t see anything in the DWARF 5 standard that would preclude multiple skeletons in the same .o, but I think this is based on the assumption that all the split units live in their respective .dwo files (or in a .dwp file). I’m not sure how you could have several skeleton/split unit pairs in a single .o in the non-split split DWARF scenario. For starters, there’s supposed to be only one split unit per .debug_info.dwo section, so I don’t know how several of them would even coexist in one object file (e.g. how they would refer to their strings in the absence of a DW_str_offsets_base attribute, the same goes for rangelists and location lists).

I think it’s as Dave says:  We’ll have to restrict support for non-split split DWARF to a single skeleton/split unit in a .o, which should make lookup fairly straightforward.

-- wolfgang

From: Robinson, Paul
Sent: Wednesday, October 24, 2018 11:56 AM
To: David Blaikie; George Rimar; Pieb, Wolfgang
Cc: llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] llvm-dwarfdump on whole-split-file fails to account for indirection through skeleton

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/30d34f95/attachment.html>