https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so I think your interpretation of PUs and CUs and using PUs for the early
DWARF and CUs for the late DWARF fits the LTO model "good enough" with the
caveat of losing info about things that are not in any way referenced by
the late CUs.
Note what the LTO DWARF currently represents is
a) early CUs represent the source at parsing time (thus no locations)
b) late CUs represent generated code and data of the early CUs with caveats:
1) not all early objects get instantiated
2) there's not a simple correspondence between early and late CUs but
a late CU instantiates selected items from multiple early CUs and there
are multiple late CUs doing that
I have patches to mitigate b) 2) a bit making it a 1:N correspondence, that is,
there are N late CUs instantiating objects from a single early CU (with the
exception of inline instances). Not sure if that helps mapping LTO reality
to DWARF terms.
So the early and late CUs together represent the program and the late CU
merely provides additional information. For functions the mental model
of abstract instances in the early CUs plus inline and concrete instances
in the late CUs works quite well since there's nothing (yet) a consumer
can do with an abstract instance that isn't instantiated in any way
(well - it could say 'it is there but optimized out', sth we lose with
the PU apporach as well). For global variables it works as long as we annotate
it (with the symbol for example). For optimized out variables with a
constant value or for things like enumeral types members it breaks
(I guess esp. that is worriesome).
And to restate - with PUs but DW_TAG_imported_unit of the same PU in multiple
places we don't win anything esp. since the instantiations via abstract
origins remain.
Using DW_AT_declaration for variables and CUs instead of PUs is IMHO the
most promising approach then.
