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


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 "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 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.