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

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

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

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

Yeah, that’s a more accurate statement of the limitation - one split unit per .dwo, therefore one unit (well, one split and its matching skeleton) when using non-split Split DWARF in a single object file.

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.

nod turns out I have a need to fix this myself now anyway - so I’m working on that, might’ve come across a bug or two along the way, we’ll see.

But yeah, simple enough to just look for the only CU in the debug_info section for now. If we end up coming up with other scenarios to support we can cross that bridge when we come to it.

  • Dave

Yep, ended up fixing this myself in r345215 - turned out one of my test cases was checking a bogus result already.

​Cool, thanks for the fix! :slight_smile: