<div dir="ltr">Hi folks,<br><br>Just a minor bug I probably won't get to but thought I should raise:<br><br>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.<br><br>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.<br><br>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).<br><br>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).<br><br>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.<br><br>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".<br><br>- Dave</div>