On Wed, Jul 26, 2017 at 10:51 AM Doug Evans <d...@google.com> wrote:
> How about a new form that specifies two things: index in .debug_addr +
> offset, where index and offset are any current constant representation
> (fixed size or leb) ?
>
Roughly what I had in mind - but wasn't sure how to encode that.
Would the type of the representation for each component be encoded at the
use? So this would be a variable length form (even when both the
index+offset use fixed length forms - because the form would be at the use,
so you'd have to read the bytes to figure out that they were using fixed
length forms)?
A two-value version of DW_FORM_indirect, I suppose?
I know the LLDB folks seem to find that fixed-width forms especially help
with parsing - not sure if GDB has a similar tendency/preference?
>
>
>
> On Tue, Jul 25, 2017 at 9:01 PM, David Blaikie <dblai...@gmail.com> wrote:
>
>>
>>
>> On Tue, Jun 27, 2017 at 5:04 PM Doug Evans <d...@google.com> wrote:
>>
>>> Heya. Again I'm not sure what help I can be here so I wasn't planning on
>>> entering the thread.
>>>
>>
>> Certainly open to ideas from you or anyone else - mostly with both these
>> threads I'm more interested in something you'd think was OK for GDB, since
>> I'd like to implement these as extensions in GDB now, rather than waiting
>> for a whole DWARF release cycle (good to have implementation experience
>> anyway)
>>
>> For opt builds this would make a huge difference, since they have many
>> relocations (many ranges, etc).
>>
>> But not a huge priority or anything.
>>
>>
>>>
>>> [just making sure you're not waiting on me]
>>>
>>> On Tue, Jun 27, 2017 at 11:48 AM, David Blaikie <dblai...@gmail.com>
>>> wrote:
>>>
>>>> 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 <dblai...@gmail.com>
>>>> wrote:
>>>>
>>>>> Ping - any ideas?
>>>>>
>>>>>
>>>>> On Wed, May 17, 2017 at 4:17 PM David Blaikie <dblai...@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)
>>>>>>
>>>>>>
>>>
>
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
