[Dwarf-Discuss] .debug_addr entry plus offset

[Greg Clayton]

One simple approach would be to be able to represent a DW_AT_low_pc with a DW_FORM_data encoding just like the DW_AT_high_pc does when it is an offset from the DW_AT_low_pc. The value of the DW_AT_low_pc would be an offset from either:
1 - the parent DIE's DW_AT_low_pc (which itself might need to be resolved by looking at the parent scope). If the parent DIE's range is a DW_AT_ranges, then use the lowest address out of all of them.
2 - the first parent DIE with a DW_AT_low_pc that has a DW_FORM_addrXXX encoding.

Solution #1 is nice because it keeps the offset in the DW_FORM_data encoding small since it is always relative to the first parent scope's DW_AT_low_pc. So this could save a lot of space in the DWARF if we use the smallest possible DW_FORM_data encoding all the time.
Solution #2 could be easier as you would traverse parent scopes looking for an address encoding as the DW_FORM.

This would allow DW_TAG_subprogram DIEs to have a single relocation on the DW_AT_low_pc.

Greg Clayton


> On Sep 15, 2020, at 10:12 AM, Robinson, Paul via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> wrote:
> 
> 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
> 
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org