[Dwarf-Discuss] address pool + offset representation

[Robinson, Paul]

>> 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
execution time).
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.

--paulr