[Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

[Simon Marchi]

>     But you've got me thinking.... Perhaps we should have *both*
>     .debug_rnglists *and* .debug_rnglists.dwo. The former could contain
>     only the range list needed for the DW_AT_ranges attribute in the
>     skeleton CU, while the latter would contain the range lists for any
>     DW_AT_ranges attributes in the dwo sections.
> 
> 
> That's what LLVM emits today, so I'm certainly in favor of it. (& that got me thinking to those relationship diagram appendices - and indeed "Figure B.2: Split DWARF section relationships" is another inconsistency, leaning towards your description, since it does not include a .debug_rnglists non-dwo section in the diagram)

And that's how GDB interprets it today (since it was updated to
understand how LLVM does it, and not yet to how GCC does it), as
illustrated by these comments:

  https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/dwarf2/read.c;h=f550a4e5008499cf94c1fa2de83b817ee6e089c3;hb=HEAD#l582
  https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/dwarf2/read.c;h=f550a4e5008499cf94c1fa2de83b817ee6e089c3;hb=HEAD#l20208

I also think that's the simplest to understand, if a DW_FORM_rnglistx
value always refers to the rnglists section in the same file.

If we also need to support producers for which DW_FORM_rnglistx values in
the .dwo refer to the rnglists section in the .o (what GCC does today,
IIUC), then this was our conclusion:

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

Simon