I want to revive the thread, but focus on whether a tombstone value
(-1/-2) in .debug_* can cause trouble to various DWARF consumers (gdb,
debug related tools in elfutils and other utilities I don't know about).
Paul Robinson has proposed that DWARF v6 should reserve a tombstone
value (the value a relocation referencing a discarded symbol in a
.debug_* section should be resolved to)
http://www.dwarfstd.org/ShowIssue.php?issue=200609.1
Some comments about the proposal:
- deduplicating different functions with identical content; GNU refers
to this as ICF (Identical Code Folding);
ICF (gold --icf={safe,all}) can cause DW_TAG_subprogram with different
DW_AT_name to have the same range.
- functions with no callers; sometimes called dead-stripping or
garbage collection.
--gc-sections can lead to tombstone values. A referenced symbol may be
discarded because its containing sections is garbage collected.
- functions emitted in COMDAT sections, typically C++ template
instantiations or inline functions from a header file;
This can cause either tombstone values (STB_LOCAL) or duplicate DIEs
(non-STB_LOCAL).
On 2020-06-03, David Blaikie wrote:
On Tue, Jun 2, 2020 at 8:10 PM Alan Modra <amo...@gmail.com> wrote:
On Tue, Jun 02, 2020 at 11:06:10AM -0700, David Blaikie via Binutils wrote:
> On Tue, Jun 2, 2020 at 9:50 AM Mark Wielaard <m...@klomp.org> wrote:
> > where I
> > would argue the compiler simply needs to make sure that if it generates
> > code in separate sections it also should create the DWARF separate
> > section (groups).
>
> I don't think that's practical - the overhead, I believe, is too high.
> Headers for each section contribution (ELF headers but DWARF headers
> moreso - having a separate .debug_addr, .debug_line, etc section for
> each function would be very expensive) would make for very large
> object files.
With a little linker magic I don't see the neccesity of duplicating
the DWARF headers. Taking .debug_line as an example, a compiler could
emit the header, opcode, directory and file tables to a .debug_line
section with line statements for function foo emitted to
.debug_line.foo and for bar to .debug_line.bar, trusting that the
linker will combine these sections in order to create an output
.debug_line section. If foo code is excluded then .debug_line.foo
info will also be dropped if section groups are used.
I don't think this would apply to debug_addr - where the entries are
referenced from elsewhere via index, or debug_rnglist where the
rnglist header (or the debug_info directly) contains offsets into this
section, so taking chunks out would break those offsets. (or to the
file/directory name part of debug_line - where you might want to
remove file/line entries that were eliminated as dead code - but
that'd throw off the indexes)
