This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Support multiple CUs in a single DWO file


With work on ThinLTO (a form of partial cross-file optimization) in
LLVM I've been looking at support for Fission/Split DWARF in this
scenario.

Basically it seems like the best representation for LTO (Thin (small
clusters of objects) and full (whole libraries/programs in a single
optimization/object file step)) is to produce a .dwo file that matches
the .o file granularity, but that means multiple CUs in that .o file
(because it represents the merging of multiple source files)

So I'd like to contribute patches to GDB to support this - the first
one I've attached (though it still lacks a test case - open to
suggestions, but I can probably figure it out on my own - just wanted
to get some feedback on the general direction & start some
conversation sooner rather than later) addresses the first error
messages about "multiple CUs in a DWO" and "cannot find DWO CU" by
keeping a map of CU signatures, the same as there's a map of TU
signatures.

Does this seem like a reasonable thing to support?
Is this the right way to go about doing it?

[The big thing I'm trying to do after this that seems more difficult &
I'd love to discuss - is supporting DW_FORM_ref_addr in these
situations. This comes up when there's cross-CU inlining (a large part
of the point of LTO-like situations) and an inlined_subroutine in one
CU needs to refer to an abstract_origin subprogram in another CU.
Currently the resolution for finding these CUs, etc, isn't quite right
for Fission]

Attachment: multiple_cus_per_dwo.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]