On Thu, Mar 11, 2021 at 2:55 AM Mark Wielaard <m...@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
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
