Split DWARF and rnglists, gcc vs clang

[Simon Marchi]

On 2020-11-13 10:18 a.m., Mark Wielaard wrote:
> That too, but I was actually referring to the sections that define
> Range List and Location List Tables (7.28 and 7.29) which define the
> meaning of DW_AT_rnglists_base and DW_AT_loclists_base. But you could
> also look at 3.1.3 Split Full Compilation Unit Entries which says that
> those base attributes are inherited from the corresponding skeleton
> compilation unit for a split unit.

Hmm, indeed, if we interpret that sentence in 3.1.3 to the letter, it
suggests that the the DW_FORM_rnglistx attributes in the DWO are meant
to point in the linked file's .debug_rnglists.  Otherwise, inheriting
DW_AT_rnglists_base wouldn't be meaningful.

But when DWO files use a .debug_rnglists.dwo section, it doesn't make
sense to consider the inherited DW_AT_rnglists_base.

So in the end the logical thing to do when encountering a
DW_FORM_rnglistx in a split-unit, in order to support everybody, is
probably to go to the .debug_rnglists.dwo section, if there's one,
disregarding the (inherited) DW_AT_rnglists_base.  If there isn't, then
try the linked file's .debug_rnglists section, using
DW_AT_rnglists_base.  If there isn't, then something is malformed.

>> What I understand from this is that the rnglist class and
>> DW_AT_rnglists_base attribute help reduce the number of relocations in
>> the non-split case (it removes the need for relocations from
>> DW_AT_ranges attribute values in .debug_info to .debug_rnglists).  I
>> don't understand it as saying anything about where to put the rnglist
>> data in the split-unit case.
>
> I interpreted it as when there is a base attribute in the (skeleton)
> unit, then the corresponding section (index table) can be found in the
> main object file.

That doesn't work with how clang produces it, AFAIU.  There is a
DW_AT_rnglists_base attribute in the skeleton and a .debug_rnglists in
the linked file, which is used for the skeleton's DW_AT_ranges
attribute.  And there is also .debug_rnglists.dwo sections in the DWO
files.  So DW_FORM_rnglistx values in the skeleton use the
.debug_rnglists in the linked file, while the DW_FORM_rnglistx values
in the DWO file use the .debug_rnglists.dwo in that file (even though
there is a DW_AT_rnglists_base in the skeleton).

> At least that is how elfutils libdw interprets the
> base attributes, not just for rnglists_base, but also str_offsets_base,
> addr_base, etc. And that is also how/when GCC emits them.
>
>>> So I believe both encodings are valid according to the spec. It just
>>> depends on what you are optimizing for, small main object file size or
>>> smallest encoding with least number of indirections.
>>
>> So, if I understand correctly, gcc's way of doing things (putting all
>> the rnglists in a common .debug_rnglists section) reduces the overall
>> size of debug info since the rnglists can use the direct addressing
>> rnglists entries (e.g. DW_RLE_start_end) rather than the indirect ones
>> (e.g. DW_RLE_startx_endx).  But this come at the expense of a lot of
>> relocations in the rnglists themselves, since they refer to addresses
>> directly.
>
> Yes, and it reduces the number of .debug_addr entries that need
> relocations.
>
>> I thought that the main point of split-units was to reduce the number of
>> relocations processed by the linker and data moved around by the linker,
>> to reduce link time and provide a better edit-build-debug cycle.  Is
>> that the case?
>
> I think it depends on who exactly you ask and what their specific
> goals/setups are. Both things, reducing the number of relocations and
> moving data out of the main object file, are independently useful in
> different context. But I think it is mainly reducing the number of
> relocations that is beneficial. For example clang (but not yet gcc)
> supports having the .dwo sections themselves in the main object file
> (using SHF_EXCLUDED for the .dwo sections, so the linker will still
> skip them). Which is also a possibility that the spec describes and
> which really makes split DWARF much more usable, because then you don't
> need to change your build system to deal with multiple output files.

Not sure I understand.  Does that mean that the .dwo sections are
emitted in the .o files, and that's the end of the road for them?  The
DW_AT_dwo_name attributes of the skeletons then refer to the .o files?

Simon