Re: Support multiple CUs in a single DWO file

[Pedro Alves <palves at redhat dot com>]

Hi David,

On 04/27/2017 07:31 PM, David Blaikie 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

I'm not sure exactly what sort of suggestion you're after, but ...
... looks like we have some dwo tests under gdb.dwarf2/fission*.exp
that I'd suggest taking a look at.  We also have a couple board
files that allow running the whole testsuite in fission/dwo
mode -- see gdb/testsuite/boards/fission*.exp.  Instructions are in
the files themselves.  Sounds like it'd be useful to add a third one?
(and now that I look at the git logs, I see you've touched those
files in the past, so you probably more about this than me.  :-) )

For DWARF-specific tests, the ideal is to write a test using the
dwarf assembler infrastructure (Dwarf::assemble), but when too difficult
we punt and allow leaving the test be arch specific.  However here it
sounds like all you'd need is a smoke test that runs the C/C++ compiler
with the right flags and makes sure you can debug the result?
Something like gdb.dwarf2/fission-mix.exp, I guess.

In case you haven't seen these yet, these may prove useful too:

 http://sourceware.org/gdb/wiki/ContributionChecklist
 https://sourceware.org/gdb/wiki/GDBTestcaseCookbook

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

I haven't really been involved in GDB's DWO support, so take it with
a grain of salt, but it sounds reasonable to me.

I'm not sure Doug Evans will have time, but given his earlier
involvement with DWO support in the past I think he'd be the best
reviewer on both direction and patches.

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

Thanks,
Pedro Alves