This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Support multiple CUs in a single DWO file
- From: Pedro Alves <palves at redhat dot com>
- To: David Blaikie <dblaikie at gmail dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Fri, 28 Apr 2017 15:37:59 +0100
- Subject: Re: Support multiple CUs in a single DWO file
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 266E54E4F5
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 266E54E4F5
- References: <CAENS6EvRvjtQ2RA02nCre41sj5+nWP9d4hqhGJaku=skZjWKXg@mail.gmail.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