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?
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
