Re: Split DWARF and rnglists, gcc vs clang

Hi Simon,

On Fri, 2020-11-13 at 10:41 -0500, Simon Marchi wrote:
> 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.

Yes, I think that makes sense.

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

I would have expected the skeleton's DW_AT_ranges to use
DW_FORM_secoffset, not DW_FORM_rnglistx. Precisely because you would
then get an ambiguity. But it would indeed be good to handle that
situation.

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

Yes, precisely. I am not sure whether it is already in any released
clang, but if it is you could try -gsplit-dwarf=single to see an
example.

Note that elfutils libdw doesn't yet handle that variant. Luckily not
because of a design issue, but because there are some sanity checks
that trigger when seeing a .debug_xxx and .debug_xxx.dwo section in the
same file. I have a partial patch to fix that and make it so that you
can explicitly open a file as either a "main" Dwarf or "split" Dwarf.
The only thing it doesn't do yet is share the file handle between the
Dwarf object (which isn't strictly needed, but would be a nice
optimization).

I actually think having a "single" split-dwarf file (.o == .dwo) is the
best way to support Split Dwarf more generically because then it would
simply work without having to adjust all build systems to work
with/around separate .dwo files.

Cheers,

Mark