# Tombstoning TU entries in .debug_names

## 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](200609.1.html) 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.