Consider emitting DWARF aranges

[cuviper]

I recently discovered that the elfutils eu-addr2line doesn't resolve locations for Rust functions. It turns out that they are expecting .debug_aranges to be valid and complete, and even treat its absence as if there are no addresses covered at all. But rustc doesn't emit aranges with its debuginfo, or at least not by default.

If you see a .debug_aranges section in your rust binaries today, that's probably only from objects compiled by GCC, like jemalloc. Try eu-readelf -waranges to see what CUs and symbols are covered. Thus even when .debug_aranges does exist, it's not necessarily complete.

Clang doesn't emit aranges by default either, but it does have the -gdwarf-aranges option to do so. This turns into the LLVM option -generate-arange-section. So it turns out that Rust can have aranges too, using rustc -Cllvm-args=-generate-arange-section. Great!

It would be nice if this were the default though. The data is usually not very big, but it can let tools map an address to the right CU very quickly, reducing the slower DIE traversals.

[dwblaikie]

Hey folks - I'm the one who turned off aranges by default in clang some time ago & I'd generally like to see less use of aranges (because it takes up extra space & so far as I know, provides little benefit)

The data is usually not very big,

Under what conditions/situations are you assessing that? In object files, the relocations for aranges can be quite significant - especially compared to the more compact rnglist encoding in use in DWARFv5 and if using Split DWARF (since the aranges don't have the more dense rnglist encoding - and there's not much other DWARF in the .o/executable file, so aranges take up quite a bit more space)

(i'll gather some data on this & follow up)

but it can let tools map an address to the right CU very quickly, reducing the slower DIE traversals.

Do you have pointers to tools that perform significantlty better (& data/numbers would be great too) on debug info with aranges compared to debug info without aranges?

I generally don't understand/haven't seen a concrete example of where aranges help compared to reading CU level ranges from the CU DIEs - parsing only the root DIEs in CUs isn't super expensive and contains all the address data you'd find in aranges (well, it doesn't include non-code addresses (global variables) - but GCC doesn't put those in aranges anyway, so most tools probably aren't expecting to find/use those there anyway)

[dwblaikie]

(oh, seems it was Eric who turned them off - but I /think/ it was based on conversations he and I were having around that time: llvm/llvm-project@02dbadb )

[dwblaikie]

Aranges doesn't take up a lot of space, admittedly, even in the worst case I can think of:
Clang self-host, -O0, -gz, -gsplit-dwarf, object files (so, including relocations): 22.2% growth of debug info (.debug_* and .rela.debug_* sections) - which is pretty significant.
An optimized build: 4.8% growth

Linked (but uncompressed - happens to be what data I have/how we use debug info at Google by default) size:
-O0: 18.5% increase in debug info size
-O3: 3.98% increase in debug info size

[cuviper]

Hi @dwblaikie! I don't have much context in my head anymore about size or performance, but my concern at the time was mostly about making sure elfutils works with Rust binaries, per their bug 22288 linked above. Even if you never use the elfutils command-line tools that mimic binutils, the libraries are still commonly used by tools like perf. If I could get you interested in that angle, I'm sure it would be nice to have gcc/clang/rustc all on the same page with appropriate tool support.

[dwblaikie]

Contributing to elfutils is a bit outside my wheelhouse (myself/my employer have no use of them in the areas I support) - though happy to provide guidance/advice.

goes to test eu-addr2line Yeah, I guess, by the looks of it, eu-addr2line just flat-out assumes .debug_aranges is present and complete? That seems wrong. It's not required by the DWARF spec (insofar as the DWARF spec requires anything) - as speculated on that bug, it'd be suitable for eu-addr2line to walk the CUs and skip any that are covered by .debug_aranges, but those that aren't covered should be parsed (a short parse to just collect ranges from the root CU DIE should be adequate for most cases - though some producers might not even include that, so a fully general implementation would, in the absence of CU address ranges, go and check child DIEs too)

Looks like binutils addr2line and llvm's llvm-symbolizer handle this OK - seems like an outright bug in eu-addr2line that should be fixed there?