Issue 231013.1: Tombstoning TU entries in .debug_names
| Author: | David Blaikie |
|---|---|
| Champion: | David Blaikie |
| Date submitted: | 2023-10-13 |
| Date revised: | |
| Date closed: | 2024-01-08 |
| Type: | Enhancement |
| Status: | Accepted |
| DWARF Version: | 6 |
Background
Local type unit entries in .debug_names reference type units via their
offset in the .debug_info section.
Assuming a non-DWARF-aware linker, per 6.1.1.3: "When linking object files containing per-CU indexes, the linker may choose to concatenate the indexes as ordinary sections ..."
If a linker does this, it will need to choose what value to resolve a
relocation for the TU offset to, if that TU was discarded. (If the TUs
are bit identical, the linker might resolve all relocations to identical
copies to refer to the remaining copy - but TUs aren't guaranteed to be
byte identical - and since the offsets in the .debug_names table refer
to specific byte offset in the TU, these entries can't be used if a
different-but-equivalent copy of the TU is the one that's preserved by
the linker.)
To deal with this, the linker would use a tombstone value of some kind
to indicate that the offset couldn't be resolved. By default, this
offset might be zero - which is a valid offset within the .debug_info
section, and would not be possible for the DWARF consumer to
differentiate the "ignore this index entry" from a valid index entry
pointing to a TU at offset zero.
With 200609.1 we chose a tombstone value for other cases (.debug_info referencing into code - in the case of discarded functions) of "the largest representable value". This seems like a good foundation for addressing this new, similar case.
Proposed Changes
Add a paragraph between the first and second/last in 6.1.1.4.3 that reads:
Any local TU entry with a maximum representable value is considered not present. Any index entry referencing such a local TU entry should be ignored.
2024-01-08: Accepted.
