[Bug debug/94450] lto abstract variable emitted as concrete decl

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 3 Apr 2020, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
> 
> --- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #9)
> > On Fri, 3 Apr 2020, vries at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
> > > 
> > > --- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
> > > (In reply to Richard Biener from comment #7)
> > > > The DW_TAG_imported_unit are now gone for GCC 10.  So can we consider this
> > > > fixed?
> > > 
> > > I'd like a PR to refer to at the to-be-added xfail in the gdb test-case (and
> > > the PR should be open as long as that test fails with trunk gcc). It doesn't
> > > matter for me whether that's this particular PR or a follow-up PR.
> > 
> > OK, so if you have a (single?) specific testcase that's still affected
> > please duplicate that into a new bugzilla.  It's always better to
> > have something specific to track.
> > 
> > So did the patch not change anything?
> 
> Well, the changes I asked for related to the example in comment 0 are:
> - drop the import
> - change the tag from DW_TAG_compile_unit to DW_TAG_partial unit.
> 
> AFAIU the patch only removes the import, so in that sense I do not consider the
> test-case reported in comment 0 addressed.

OK, fair enough.  Note that as I read the DWARF spec changing the
early CUs to DW_TAG_partial_unit and then again importing those
(the spec suggests you need to import DW_TAG_partial_units) would
not reflect documented semantics either.  While the early CUs
represent the original TUs declarations the actual instantiation
is split into multiple late CUs.  Currently we import the early CUs
in each late CU that instantiates at least _one_ of the early CU
entities.  But as I read the SPEC importing a partial CU means
the importing CU will be an instantiation point for _all_ entities
in the imported partial CU.

So there may not be a good fit for the LTO usage where we have
"abstract" units for each TU and "concrete" units for each
LTRANS unit picking items to instantiate from various abstract CUs.

Splitting the early CUs into multiple DW_TAG_partial_units, one
for each object, and selectively only importing the instantiated
ones might make it fit better but we then likely have to force
the use of type units to carry type DIEs.  Note we'd still import
the abstract unit for a function when the function is only
instantiated inline and elsewhere instantiated concrete.

So somehow making the early CUs "abstract" might be a better
approach (not sure how gdb would like to have the DWARF represented
then).