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@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@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
