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

[Mark Wielaard]

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

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

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

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

Thanks,

Mark