Re: Support multiple CUs in a single DWO file

[David Blaikie <dblaikie at gmail dot com>]

On Fri, Apr 28, 2017 at 7:37 AM, Pedro Alves <palves@redhat.com> wrote:
> 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.  :-) )

Heh - sure enough. But it's been quite a while - I really do
appreciate the reminders & did eventually find something to model from
(fission-base.exp) in there.

> For DWARF-specific tests, the ideal is to write a test using the
> dwarf assembler infrastructure (Dwarf::assemble),

I'll go see if I can figure that out, but will also start a new thread
with a test case, ChangeLog entry, proper subject line, update on the
issues/resolutions surrounding this, etc.

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

Not sure how practical or useful such a test would be - I'm going to
assume GCC doesn't produce any debug info like this at the moment & I
don't know of anyone who's regularly running the GDB test suite with
Clang. (I mean, there is (I added) support for special casing clang in
test cases: "if {[test_compiler_info {clang-*-*}]} {" in a couple of
places)

> 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

Thanks!

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

*nod* I'll CC you on the new thread & see what Doug's got to say about
it before trying to search for other reviewers, etc.

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

Turns out this ^ is a longer project, since the DWP format can't
doesn't capture enough info to support ref_addr. So for now I've
modified Clang not to do this (but still, multiple CUs per DWO is
nice/handy to have, even without cross-CU references) while I fix up
DWP and consumers - so patches to GDB eventually, but not as
immediate.

Thanks again!
- Dave