[Dwarf-Discuss] address pool + offset representation

[David Blaikie]

Ping

This'd be a great file size saving, especially in optimized builds - and
probably link time optimization by having /many/ fewer relocations.

On Wed, May 31, 2017 at 1:25 PM David Blaikie <dblaikie at gmail.com> wrote:

> 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/20170627/2e21877f/attachment-0001.htm>