Split DWARF and rnglists, gcc vs clang

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

Hi,

I'm currently squashing some bugs related to .debug_rnglists in GDB, and
I happened to notice that clang and gcc do different things when
generating rnglists with split DWARF.  I'd like to know if the two
behaviors are acceptable, and therefore if we need to make GDB accept
both.  Or maybe one of them is not doing things correctly and would need
to be fixed.

clang generates a .debug_rnglists.dwo section in the .dwo file.  Any
DW_FORM_rnglistx attribute in the DWO refers to that section.  That
section is not shared with any other object, so DW_AT_rnglists_base is
never involved for these attributes.  Note that there might still be a
DW_AT_rnglists_base on the DW_TAG_skeleton_unit, in the linked file,
used if the skeleton itself has an attribute of form DW_FORM_rnglistx.
This rnglist would be found in a .debug_rnglists section in the linked
file, shared with the other units of the linked file.

gcc generates a single .debug_rnglists in the linked file and no
.debug_rnglists.dwo in the DWO files.  So when an attribute has form
DW_FORM_rnglistx in a DWO file, I presume we need to do the lookup in
the .debug_rnglists section in the linked file, using the
DW_AT_rnglists_base attribute found in the corresponding skeleton unit.
This looks vaguely similar to how it was done pre-DWARF 5, with
DW_AT_GNU_ranges base.

So, is gcc wrong here?  I don't see anything in the DWARF 5 spec
prohibiting to do it like gcc does, but clang's way of doing it sounds
more in-line with the intent of what's described in the DWARF 5 spec.
So I wonder if it's maybe an oversight or a misunderstanding between the
two compilers.

But if both ways are correct, then we just need to know so we can
implement it in GDB.  Although we'll probably need to implement reading
what gcc currently produces, since it's already in the wild.

Simon