[Dwarf-Discuss] Fission + cross-CU references (ref_addr)

[David Blaikie]

ping

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

> Pinging this thread & bringing it to the attention of Cary & Doug in case
> they've got some thoughts.
>
> I'd love to have some kind of ideas about this to work on an
> implementation in GDB (as an extension/prototype).
>
> (don't mean to dismiss Paul's suggestion - and I generally agree with it,
> except where it gets a bit difficult when type units are folded into
> debug_info (Paul's suggestion requiring some kind of grouping within a
> section ("contributions") which seems like a new constraint/detail I
> wouldn't think to have here))
>
> On another thread Cary talked about the idea of avoiding ref_addr and
> expanding the functionality of DW_FORM_sig8/signature and perhaps
> generalizing the type unit header to allow multiple hash+offset pairs. This
> is a feature Adrian & I had talked about previously (when looking at the
> overhead of type units - the need to duplicate member function declarations
> in any unit that has a definition of the member function, since the
> specific DIE in the type unit couldn't be referred to from the definition
> in the CU) & I think would be great (& would further generalize the unit
> header - no need for a difference between TU and CU header, instead have a
> "count" & then that many {hash, offset} pairs for referring to any DIEs
> from elsewhere). Might not be the perfect solution to the CU->TU
> references, since signatures are large-ish. So might require a bit more
> care/data/etc.
>
> I'm also not sure/don't think I'd have the time to push that ^ feature, as
> much as it is a nice one. Paul's cu_index column extension wouldn't be too
> hard to implement, I think.
>
>
> On Tue, May 2, 2017 at 12:09 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> I've recently been trying to resolve the use of Fission in LLVM's ThinLTO
>> mode (though this would apply to plain LTO too).
>>
>> One of the things that happens here is that cross-CU DIE references
>> (DW_FORM_ref_addr) are used to describe inlining a function in one CU into
>> another CU.
>>
>> This format has been implemented in LLVM and GCC for ~years and seems to
>> work well outside of Fission.
>>
>> So the question is: what to do with Fission?
>>
>> It seemed to me that a good representation would be to produce multiple
>> CUs into a single DWO file, which GDB can't yet consume, but I'm working on
>> patches to help there. DW_FORM_ref_addr would not use any ELF relocation,
>> but be assumed to be "relative to the chunk of debug_info it was in"
>> (within the .dwo file)
>>
>> But what about DWP files? Currently binutils dwp produces records like
>> this:
>>
>> (this dwp contains 3 CUs, two from one LTO compile, and one from a
>> standalone compile linked in for comparison):
>>
>> Index Signature          INFO     ABBR     LINE     STR_OFF
>> ----- ------------------ -------- -------- -------- --------
>>     2 0x7bd765349b7e7631 [2d, 65) [38, ae) [11, 22) [14, 3c)
>>     8 0x66f4e160661d2687 [00, 2d) [00, 38) [00, 11) [00, 14)
>>    11 0x32dd6d7121dd1d9a [65, 98) [38, ae) [11, 22) [14, 3c)
>>
>> So the ABBR/LINE/STR_OFF sections are kept as-is (no analysis is done to
>> find which portions of the dwo file are used by which CUs, etc), but the
>> INFO section is fragmented on the CU boundaries. Fragmenting the TYPES
>> section on the TU boundaries is necessary/useful for deduplication of
>> types, but this fragmenting of the CU makes it impossible (I think) to use
>> ref_addr in a dwp file.
>>
>> If this fragmenting were not done - consumers (GDB, etc) would need to
>> change to account for this - searching through the INFO range to find the
>> CU matching the signature, rather than knowing it starts at the start of
>> the INFO range. This could have a noticeable performance impact especially
>> in a full LTO build (where /all/ the CUs were in the same .dwo - so the
>> index would be entirely unhelpful, I think).
>>
>> Does all this sound right/sane - anyone have ideas/perspectives/thoughts
>> on how this should work?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20170627/2573c0b4/attachment.htm>