[Dwarf-Discuss] address pool + offset representation

[David Blaikie]

A big part of Fission debug info in object files an optimized build, are
unique address relocation in debug_addr and debug_ranges. I have an example
binary where for N bytes of .text, there are ~2N bytes of .rela.debug_addr
and >2N bytes of .rela.debug_ranges.

Given that .rela.debug_line is about ~1% of the size of .text - that gives
a sense of the lower bound - there should be only a few more relocations
needed in .debug_addr than in .debug_line (relocs for global variables).

This arises because things like low_pc (for each subprogram and then each
lexical block inside it) use distinct addresses in the address pool, when
they could use an offset relative to some other known address in the pool
(basically one address for each .text section - and everything would use
that + offset).

The new *x (startx*, base_addressx) forms in the debug_rnglists format
address the relocations for the debug_ranges section - allowing it to reuse
addresses in debug_addr.

But to address debug_addr's redundancy, it'd would be nice to have an
abbreviation form to represent "address in the pool, plus a constant
offset".

What form should this take?

Currently there's addrx{,1-4} - a LEB128, or 1-4 byte fixed-length
representation.
Similarly the offset between addresses could be a variety of lengths.
high_pc for example allows for any form of the constant class.

Should this support the combination of all of these forms
(addrx{,1-4}*data{,1-4}). Or is there some better option?

I hope to try prototyping this as a GNU extension form if/when people have
some idea of what might be best for the representation.


Bonus points: It'd be great to move the address pool into the line table -
then it'd be really one relocation per section. That'd need a new assembly
directive, though. Anyone got ideas on that too? (this would be orthogonal
to the above improvement - both things are good to do)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20170517/eb0a40fe/attachment.htm>