Previously, if --gdb-index is not given, we copy .debug_gnu_pub{names,types}
sections to an output file, which is just a waste of disk space.
If the input sections are compressed, doing it also wastes CPU and memory
because, in order to copy them, we need to uncompress them first.
Details
- Reviewers
dblaikie • espindola echristo MaskRay
Diff Detail
- Build Status
Buildable 22807 Build 22807: arc lint + arc unit
Event Timeline
It's possible another tool (gdb itself, for example) could read these sections and construct an index themselves - just later on, but still more efficient than parsing all the DWARF, etc. So I'm not sure if this should be the default or only behavior (not saying it shouldn't be - I'm genuinely unsure).
Did you find this behavior to be a problem in some real-world case? Presumably the user would be better off turning off pubnames to reduce object size, rather than producing them and not using them?
What I found is lld consumes a lot of memory when we feed object files containing .zdebug_gnu_pub{names,types} sections because it uncompresses them in memory. I don't know how realistic that scenario is, but that's at least I tried.
Currently, if no --gdb-index is given, lld just concatenates .{,z}debug_gnu_pub{names,types} by section name because that's the default behavior of the linker. Can external tools consume such concatenated sections?
What I found is lld consumes a lot of memory when we feed object files containing .zdebug_gnu_pub{names,types} sections
... even if --gdb-index is not given
Yep - like most DWARF sections (I think maybe only the apple accelerator tables missed this), they're designed to be concatenated safely - they include a relocation to the CU they index in their header. So each chunk can be appropriately attributed.
The gdb command save gdb-index can produce symbol-file.gdb-index, but it seems it does not need .debug_gnu_pub{names,types}
In the binutils-gdb repo:
% rg -l debug_gnu_pubnames gold/ChangeLog-0815 binutils/dwarf.c binutils/ChangeLog-2013 gold/testsuite/dwp_test_1.s gold/testsuite/dwp_test_1b.s gold/testsuite/dwp_test_main.s gold/testsuite/dwp_test_2.s binutils/doc/debug.options.texi debug/binutils/doc/objdump.1 debug/binutils/doc/readelf.1 gdb/testsuite/gdb.dwarf2/fission-loclists-pie.S gdb/testsuite/gdb.dwarf2/fission-base.S gdb/testsuite/gdb.dwarf2/fission-loclists.S
The three gdb tests mention .debug_gnu_pubnames just because they are created by -gsplit-dwarf, not because that gdb itself does anything with them.
This looks fine. For extra safeguard you may ask if .debug_gnu_pubnames is useful on the gdb mailing list gdb@sourceware.org
Doesn't need it - but the data can be used (not sure if GDB does use it, admittedly - but the data is meaningful even without a linker index builder) so it seems a bit weird to me to have the linker silently strip it out.
Still feels strange to me to strip a perfectly usable section silently like this. If the user doesn't want these sections they can pass -gno-pubnames to the compiler and avoid generating them in the first place.
I submitted https://reviews.llvm.org/rL343979 which also reduce memory consumption for .zdebug_gnu_pub{names,types} sections, so I don't think we need this anymore.