[Dwarf-Discuss] address pool + offset representation

[David Blaikie]

Ping - any ideas?

On Wed, May 17, 2017 at 4:17 PM David Blaikie <dblaikie at gmail.com> wrote:

> 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/20170531/4b25490a/attachment.htm>