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 rguent...@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).
