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

[David Blaikie]

On Wed, Mar 10, 2021 at 2:36 PM Cary Coutant <ccoutant at gmail.com> wrote:

> On Wed, Mar 10, 2021 at 1:27 PM David Blaikie <dblaikie at gmail.com> wrote:
> >
> > On Wed, Mar 10, 2021 at 1:16 PM Cary Coutant <ccoutant at gmail.com> wrote:
> >>
> >> > But what about the DW_AT_ranges on the skeleton CU when using split
> DWARF?
> >> >
> >> > Are you suggesting that both LLVM and GCC's emission is incorrect -
> and that it's not possible to use rnglistx in the skeleton CU (instead you
> must use sec_offset for DW_AT_ranges on the skeleton CU)? (& that there's
> no way to refer to range lists in the .o (debug_rnglists) from the .dwo -
> all ranges in the split full unit must be in debug_rnglists.dwo?)
> >>
> >> If you've moved range lists over to the dwo, having DW_AT_ranges in
> >> the skeleton CU would be pointless ? the consumer would still have to
> >> go find the dwo to get the ranges.
> >>
> >> For the case you suggested where it would be useful to keep the range
> >> list for the CU in the .o file, I think .debug_aranges is what you're
> >> looking for.
> >
> >
> > aranges has been off by default in LLVM for a while - it adds a lot of
> overhead (doesn't have all the nice rnglist encodings for instance - nor
> can it use debug_addr, and if it did it'd still be duplicate with the CU
> ranges wherever they were).
> >
> > DWARFv5 says:
> >
> > "A skeleton compilation unit may have additional attributes, which are
> the same as for conventional compilation unit entries except as noted, from
> among the following:
> >   2. Either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a
> DW_AT_ranges attribute."
> >
> > and
> >
> > "The following attributes are not part of a split full compilation unit
> entry but instead are inherited (if present) from the corresponding
> skeleton compilation unit: DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, ..."
> >
> > Even before the rnglist move, this still disallowed using
> DW_AT_low/high_pc with addrx encodings from the split full unit, instead
> requiring them to be in the skeleton unit. I think this is the right call
> (& guess it was motivated by this use case) to make for cheap unit lookup.
>
> Hmm. I'm thinking that wording is from before the rnglist move, and
> did not get updated properly. Or maybe it was intentional, but not
> thought all the way through. Forcing DW_AT_ranges to be in the
> skeleton CU when the actual range lists are in the dwo is silly.
> DW_AT_low_pc/_high_pc in the skeleton makes sense, though.
>

Why one but not the other? Pre-range move, we could've still had smaller
skeleton CUs (& thus smaller objects/executables) if low/high/ranges were
all in the split full unit - using addrx and the v4 fission prototype style
ranges_base-relative offsets.

Yeah, the wiki write up for Fission ( https://gcc.gnu.org/wiki/DebugFission
) doesn't mention the motivation for DW_AT_low_pc, DW_AT_high_pc,
DW_AT_ranges, and DW_AT_stmt_list to be in the skeleton unit. stmt_list
makes sense because it needs to be relocated to refer to the .debug_line
contribution wherever it's linked in. (oh, I guess there's another use case
for low/high/ranges in the .o - it means you can symbolize (without inline
stack frames) without dwo files present - and with two level line tables
you could do full symbolization without dwo files)

In any case I disagree that forcing ranges to be on the skeleton CU is
silly - it's important to use cases I care about/support (& I think is
pretty generally a good idea, but wouldn't strenuously object if someone
really wanted the freedom to put it in the split full unit if they really
want to/have a use case).

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)

Which comes back to the "what does rnglists_base on a skeleton .o file
mean, if anything" - should the ranges on the skeleton CU always use
sec_offset (never rnglistx), or can you use rnglists_base on the skeleton
CU , rnglistx in both skeleton and split full - and the rnglistx in the
split full unit always refer to rnglists.dwo no matter what's going on in
the skeleton - and the rnglistx in the skeleton uses the rnglists_base?
That's what LLVM does today and seems consistent/general.

I'd say the fix to the wording would be to say that DW_AT_rnglists_base is
not inherited by the split full CU from the skeleton CU, and split full CUs
effectively always have an implicit rnglists_base of <sizeof rnglists
header>. (plus fixing the block diagram)


> If you (LLVM) are already choosing not to use .debug_aranges for quick
> address lookup, does that suggest that per-CU ranges are sufficient?
>

Yes


> Can we get rid of .debug_aranges?
>

I think that would be good as far as my use cases & other uses I can think
of are concerned - but I think I remember there being some reasonable
disagreement there last time it was discussed maybe in the LLVM community
(arangas is off-by-default, but LLVM can produce them when asked and I
think some users do turn them on)

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20210310/2ef1e87d/attachment.html>