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] |
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] |