[Dwarf-Discuss] .debug_addr entry plus offset

[Robinson, Paul]

David Blaikie has brought this up with me (or in conversations that
I observed) a couple of times:

It's common to want to refer to a particular address plus an offset,
for example for DW_AT_low_pc or DW_AT_ranges to describe a lexical
block or inlined subprogram within another subprogram.  Generally
the only symbolic address available is the entry point of the
containing subprogram.  Back when addresses were held directly in 
the .debug_info section, the attributes would have relocations, the
offset would be encoded into the relocation and the linker would
just do the right thing.

With DWARF v5, we now have the .debug_addr section, which contains
the addresses to be fixed up by the linker.  But, we don't have a
way to specify an offset to add to an entry in the .debug_addr
section; instead, each unique addr+offset requires its own entry
in the .debug_addr table.  This consumes additional space, these
entries are generally not reusable, and it doesn't reduce the
overall number of relocations that the linker must process.

It's not feasible to define a new attribute for address+offset,
because an attribute has only one value, and the attribute would
have to specify both the .debug_addr index and the offset to add.
But, we could define an "indirect" entry in .debug_addr, and then
reference it with an attribute in the same way that we reference
any other .debug_addr entry.

An indirect entry would be the same size as all other entries in 
.debug_addr (i.e., the size of an address on the target).  The
upper half would be another index into .debug_addr and the lower
half would be the addend.  The consumer adds the addend to the
value from the entry specified by the "another index."

This solution doesn't save space in .debug_addr, but it does
reduce the number of relocations.  Ideally .debug_addr would
require only one relocation per function.

We can debate whether the addend should be signed or unsigned,
and whether the indirect entries should be a separate subtable,
but I wanted to float the idea here before I wrote it up as a
proposal.

Alternatively, the indirect sub-table could be encoded with
ULEB/SLEB pairs, but that makes it hard to find them by index.
They could be found by a direct reference, but that requires a
relocation from .debug_info to .debug_addr, so we haven't saved
any relocations that way.

If there are obvious flaws I can't see, or someone is inspired
to come up with another solution, please let me know!  Otherwise
I'll write it up as a formal proposal probably later this week.

Thanks,
--paulr