More split dwarf work #529
Conversation
Why does this matter? Shouldn't those values be set by the attributes? From memory, the reason we need defaults for the GNU extensions is because they don't use those attributes. Edit: and trying to set defaults doesn't accomplish anything because they will only be correct for the first unit.
They aren't mutually exlusive. An executable can contain both DWARF 4 and DWARF 5 debuginfo since each object file can be compiled with different settings. Edit: doesn't allowing multiple dwo section names fix the problem this was trying to solve? |
The attributes are not always present. e.g. clang does not emit the attributes if the values are the defaults.
Ugh, that's obnoxious. Is that really something we care to support? The alternative here is probably to add a new |
From what I can tell, that's only for split DWARF, and it works because these values should be inherited from the skeleton unit. So the correct fix is to inherit those values, instead of guessing where it will be. I can be convinced otherwise if you can show me code in a consumer (e.g. gdb or lldb) that calculates these values instead.
Yes. It probably occurs more due to objects being produced by different tools rather than different settings. There's less of a case for it in split DWARF, but we definitely need to support it otherwise. In split DWARF, I think it would be fine to treat the |
|
So the bug is that |
Right.
No. There are four sections with relevant base attributes: I thought clang sometimes omitted the
gdb doesn't actually support DWARF 5. lldb is doing similar calculations at https://github.com/llvm/llvm-project/blob/e808cab824488af137b62902e65dec3827b83b46/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp#L425. LLVM parses the section headers so it's adjusting the specified offsets down. We're not so we need to adjust the default offset up.
Yeah ok that's not super-terrible then. |
|
Table F.1 in the DWARF 5 spec is pretty clear about how the base attributes work. |
|
Ok I can see that clang does calculate the header size in some cases. Still trying to understand how what you have said matches this text from the standard:
This recently was discussed on the dwarf mailing list, and the conclusion is this is an error in the standard. Edit: that was actually talking about skeleton units. I'll take some time to understand this properly. |
The text is wrong. Having
How, exactly? |
That doesn't actually help because the same encoding is used to choose between Put another way, in the DWARF 4 GNU split dwarf case |
Right, so that check needs changing too. The sections aren't mutually exclusive, but their use within a unit is. So I think which format to use needs to be derived from properties of the unit (its version) and the file (is it a DWO?). Does that sound right? |
That's right, but currently nothing in gimli knows about DWARF v4 split dwarf files at all. I guess we could pass that information into |
|
I think your changes to the base attribute defaults are good, but I'll look at it a bit more later to make sure I understand. |
|
I think actually I should push the branching on the version into |
…utes to just after the section header in DWARF 5 .dwos. Of the four sections with corresponding base attributes (.debug_addr, .debug_str_offsets, .debug_loclists, and .debug_rnglists), only .debug_addr must be linked into the final executable in DWARF 5. The other three sections can be left behind in a .dwo file. In this case, a compiler (e.g. clang 11) can omit the base attribute value for the sections left behind in the .dwo because, since there is only one split CU represented in the .dwo, there is no ambiguity. However, gimli relies on these offsets to skip past the DWARF 5 section headers, so we need to change the default values here to point beyond the section header. Note that the DW_AT_str_offsets_base attribute value may be present on the corresponding skeleton unit in the main DWARF file. This is controlling *only* for string attributes on that single DIE (for e.g. its DW_AT_comp_dir attribute). The only base value present on the skeleton unit in DWARF 5 that affects the split unit in the .dwo file is the DW_AT_addr_base value.
…dard split DWARF setup. The GNU split DWARF extension uses a single .debug_ranges section in the final binary and a DW_AT_GNU_ranges_base attribute, while the standardized DWARF 5 version uses a .debug_rnglists table that remains in the .dwo and does not require relocation, and thus no rnglists_base attribute is needed.
khuey
force-pushed
the
downstream
branch
2 times, most recently
from
7dda08e to
a3964b3
Compare
|
Alright how about this version? |
…he encoding, and add new _dwo methods on LocationsList that always use the new section and encoding regardless of the DWARF version to support the non-standard GNU split dwarf extension.
|
Comments addressed. |
The pre-DWARF5 GNU split dwarf extension differs from the standardized version in at least two ways:
Additionally, the default values for the various base attributes are wrong in DWARF 5, where there is the section header (that is not present in the GNU split dwarf extension) that must be skipped.
To handle all of this, I fix the default base handling by keying off the DWARF version, then I refactor LocationLists and RangeLists because only one of the two sections is present at any given time. Which encoding to use for these lists is no longer keyed off the DWARF version but rather the section in use. That allows the DWARF version to be used to distinguish the pre-DWARF5 GNU split dwarf encoding for location lists.