[Dwarf-Discuss] address pool + offset representation
Wed Jul 26 23:27:19 GMT 2017
>> Well... why not just use ranges, in that case?? .debug_rnglists is
>> already tuned to reduce relocations.? A range list with only one
>> entry is the same as a contiguous range, and DW_RLE_offset_pair is
>> basically the same as using constant low_pc and high_pc.
> Fair point/question (I was going to say I wasn't sure if gdb supported
> rnglists yet, but grepping the source it looks like it probably does -
> though LLVM can't/doesn't produce them yet, it would be a good thing,
> even aside from this particular issue).
The new range lists are on my list of DWARF 5 features to do in LLVM.
> Certainly would be a thing to prototype/a valid representation that
> would reduce the number of address relocations/size of object files
> (under split DWARF at least).
> But I imagine that representation might be a bit larger overall/more
> expensive to parse?
Well, if you want to minimize relocations, you can have:
- DW_AT_ranges with a LEB index into the rnglists section;
- one 4-byte entry in the rnglists header to point to the actual
range list; (or 8-byte entry in DWARF-64 format);
- the range list itself which would be:
o DW_RLE_offset_pair (1 byte entry code plus 2 LEBs)
o DW_RLE_end_of_list (1 byte entry code)
So 2 bytes plus 2 LEBs. This assumes using the unit's base address.
If we're not using the unit's base address, we add 1 byte and 1 LEB
to select the base address in the .debug_addr section.
Grand total is 6 bytes plus 3 LEBs (or 7 bytes and 4 LEBs if we can't
use the unit's base address).
Versus DW_AT_low_pc, one address-sized value and a relocation, or
one index into .debug_addr and the same relocation.
Or DW_AT_low_pc-as-constant, which is likely the smallest but does
have the drawback that to compute this DIE's low_pc you need to
find the parent's low_pc (or the nearest parent that has a low_pc).
I *really* don't think a two-operand kind of FORM will ever fly.
So the range-list approach is a bit bigger, but one .debug_addr entry
can act as the base for everything in the section so essentially
relocation costs are eliminated (both size in .o files and linker
It might also be cost-effective to pre-parse the rnglists section,
could easily be done in parallel with reading other info sections.
The low_pc solutions really don't feel like they could be done in
parallel with anything else.
More information about the Dwarf-discuss