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

[David Blaikie]

On Thu, Mar 11, 2021 at 2:55 AM Mark Wielaard <mark at klomp.org> wrote:

> Hi David,
>
> On Thu, Mar 11, 2021 at 01:01:05AM -0800, David Blaikie wrote:
> > +Mark in case he's got further context/perspective to share in the
> context
> > of this thread
>
> I haven't yet caught up on the mailinglist, but I think I understand
> the context, it was a discussion Simon and I had about how to handle
> .debug_rnglists in the main object file vs the split object.
>
> > One particular thing I'll pull out of the gdb-patches thread is:
> >
> > "But the rnglists
> > (loclists) themselves can still use relocations. A large part of them
> > is non-shared addresses, so using indexes (into the .debug_addr
> > addr_base) would simply be extra overhead."
> >
> > That's not quite right - while a direct mapping from debug_loc and
> > debug_ranges (at least location and range lists not using base address
> > selection entries) to debug_loclist and debug_rnglist would produce a
> > similar number of addresses and relocations - there's a lot to be gained
> by
> > using DW_RLE/LLE_base_addressx entries - then you can strategically reuse
> > an already-existing debug_addr entry and avoid another relocation all
> > together (debug_loc and debug_ranges couldn't do this, even when using a
> > base address selection entry - that base address couldn't be shared with
> > other lists, since it was inline).
>
> I admit I didn't implement anything to measure. So I can certainly be
> convinced of the opposite. But if your strategically reuse algorithm
> can also identify when it isn't strategic, then just not having an
> indirection for that address through the .debug_addr index is still a
> win. It just means you don't get to move the relocation to the
> .debug_addr. But I see why this is still important because...
>

Yeah - I haven't implemented anything in LLVM to bail out and avoid addrx
when there isn't another use of the address in DWARFv5 non-split because I
don't have much use for non-split (Google's not switched to split by
default, but that's the mode to use when size matters - so optimizing
non-split for size isn't a high priority for me) and there's no case I know
of where DW_AT_low_pc or any address in DW_AT_ranges wouldn't be used in at
least one other place: all those addresses will be used as the starting
address of a subprogram at least, so that's at least two uses.


>
> > also, as to the original motivation for Split DWARF (reduce object size,
> > reduce relocations, etc) - mostly a distributed build system where the
> cost
> > of shipping all the object files to the link step is a significant
> > bottleneck - so reduced object size (so reducing the DWARF object size -
> > which is both .debug_* sizes, and .rela.debug_* sizes equally - well,
> > except we do use -gz so .debug_* sizes are much smaller, but
> .rela.debug_*
> > is not compressed - so reducing relocations is /extra/ important).
>
> Although I see how a distributed build system where there is a cost of
> shipping object files to the linker might be a motivating factor. I
> also think that isn't a common setup. So yes to reducing relocations,
> having less work for the linker to do. But reducing transport cost
> wouldn't be that high on my list.
>

Fair enough - yeah, it boils down to similarly, as you said, fewer actions
for the linker to perform (both in terms of relocations to apply, and in
terms of bytes to write to the output file/linked executable (&
subsequently/also a smaller final linked executable)).


> > (I went to look a bit further and GCC's .debug_loclists.dwo but it seems
> > there's something about it that llvm-dwarfdump can't understand - it only
> > prints a handful of rather mangled location lists... not sure which
> > component (GCC, llvm-dwarfdump, or both) is getting things confused here
> -
> > oh, maybe some kind of DWARF extension for the "views" system, by the
> looks
> > of it)
>
> Yes, you might try -gno-variable-location-views or simply use binutils or
> elfutils readelf to look at them.
>

Thanks! - is this proposed as a DWARF extension? I thought I remembered it
coming up, but hadn't realized how non-standard it was/that it was already
implemented. (quick search on the issues page and I can't find any mention
of it at least)

(aside: Hmm, readelf doesn't have support for the offset entry tables in
either rnglists or loclists, I think:

readelf: Warning: The .debug_rnglists section contains unsupported offset
entry count: 2819.)

Unrecognized debug section: .debug_loclists.dwo

But, yeah, using readelf on a non-split-DWARF build I see these "location
view pair"s showing up.

I think you did convince me we need to look at smarter .debug_addr usage.
>

Great! Happy to chat about it further any time! I can point you to some of
the patches in LLVM and/or provide examples that demonstrate the
interesting cases of reuse.

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