Re: Split DWARF and rnglists, gcc vs clang

[Mark Wielaard <mark@klomp.org>]

Hi Simon,

On Fri, 2020-11-13 at 09:45 -0500, Simon Marchi wrote:
> I think I would have asked the question the other way around :) The
> > spec explicitly describes rnglists_base (and loclists_base) as a way
> > to reference ranges (loclists) through the index table, so that the
> > only relocation you need is in the (skeleton) DIE.
> 
> I presume you reference this non-normative text in section 2.17.3?
> 
>     This range list representation, the rnglist class, and the related
>     DW_AT_rnglists_base attribute are new in DWARF Version 5. Together
>     they eliminate most or all of the object language relocations
>     previously needed for range lists.

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.

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

> > P.S. I am really interested in these interpretations of DWARF, but I
> > don't really follow the gdb implementation details very much. Could we
> > maybe move discussions like these from the -patches list to the main
> > gdb (or gcc) mailinglist?
> 
> Sure, I added gdb@ and gcc@.  I also left gdb-patches@ so that it's
> possible to follow the discussion there.

Thanks,

Mark