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

[David Blaikie]

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/20170531/5669bc0e/attachment.htm>