Re: Support multiple CUs in a single DWO file

["Doug Evans via gdb-patches" <gdb-patches at sourceware dot org>]

On Thu, Apr 27, 2017 at 11:31 AM, David Blaikie <dblaikie@gmail.com> wrote:
>
> 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?



Heya. Getting caught up.
Whether it's reasonable or not I guess is being asked in the context
of not being sure what DWARF will eventually be for this?
Sounds reasonable (within some epsilon of some definition of
"reasonable") to me at first glance.


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



Happy to discuss. Lunch?