public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/94450] lto abstract variable emitted as concrete decl
Date: Fri, 03 Apr 2020 16:43:01 +0000 [thread overview]
Message-ID: <bug-94450-4-eeSsofUF3G@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94450-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at gcc dot gnu.org
--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #11)
> 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.
It's not my understanding from the spec that DW_TAG_partial_units are required
to be imported. AFAIU, it's just that in all the use-cases there using
DW_TAG_partial_unit, an import happens to be required.
OK, so lets look at the use cases described in the spec at E.1.
I. classic dwz: factor out into partial unit, add imports:
...
DW_TAG_compile_unit
DW_AT_name cu1
L1: DIEx
DIEy
DW_AT_type L1
DW_TAG_compile_unit
DW_AT_name cu2
L2: DIEx
DIEz
DW_AT_type L2
->
L3: DW_TAG_partial_unit
L4: DIEx
DW_TAG_compile_unit
DW_TAG_imported_unit
DW_AT_import L3
DW_AT_name cu1
DIEy
DW_AT_type L4
DW_TAG_compile_unit
DW_TAG_imported_unit
DW_AT_import L3
DW_AT_name cu2
DIEz
DW_AT_type L4
...
II. dwz --devel-uni-lang --devel-gen-cu: factor out into DW_TAG_compile_unit,
no imports, exploit global namespace:
...
DW_TAG_compile_unit
DW_AT_name cu1
L1: DIEx
DIEy
DW_AT_type L1
DW_TAG_compile_unit
DW_AT_name cu2
L2: DIEx
DIEz
DW_AT_type L2
->
DW_TAG_compile_unit
L4: DIEx
DW_TAG_compile_unit
DW_AT_name cu1
DIEy
DW_AT_type L4
DW_TAG_compile_unit
DW_AT_name cu2
DIEz
DW_AT_type L4
...
III. #include in namespace:
...
DW_TAG_compile_unit
DW_AT_name cu1
DW_TAG_namespace bla1
L1: DIEx
DIEy
DW_AT_type L1
DW_TAG_compile_unit
DW_AT_name cu2
DW_TAG_namespace bla2
L2: DIEx
DIEz
DW_AT_type L2
->
L3: DW_TAG_partial_unit
L4: DIEx
DW_TAG_compile_unit
DW_AT_name cu1
DW_TAG_namespace bla1
DW_TAG_imported_unit
DW_AT_import L3
DIEy
DW_AT_type L4
DW_TAG_compile_unit
DW_AT_name cu2
DW_TAG_namespace bla2
DW_TAG_imported_unit
DW_AT_import L3
DIEz
DW_AT_type L4
...
So indeed, in all cases where DW_TAG_partial_unit is used, we use an import,
but that's because it's applicable to the transformation, and we're just doing
an entirely different transformation here:
...
DW_TAG_compile_unit
DW_AT_name cu1
DW_TAG_variable
DW_AT_name var1
DW_AT_location
->
DW_TAG_partial_unit
L1: DW_TAG_variable
DW_AT_name var1
DW_TAG_compile_unit
DW_AT_name cu1
DW_TAG_variable
DW_AT_abstract_origin L1
DW_AT_location
...
We fabricate a new abstract DW_TAG_variable DIE out of thin air, then try to
hide that fact by placing it in a DW_TAG_partial_unit, much like is done at
III. Only in contrast to III, we don't want to reintroduce it in another
context, we want it to keep hidden, so there's no import.
prev parent reply other threads:[~2020-04-03 16:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 21:51 [Bug debug/94450] New: " vries at gcc dot gnu.org
2020-04-02 8:07 ` [Bug debug/94450] " rguenth at gcc dot gnu.org
2020-04-02 10:17 ` rguenth at gcc dot gnu.org
2020-04-02 10:22 ` rguenth at gcc dot gnu.org
2020-04-02 10:25 ` rguenth at gcc dot gnu.org
2020-04-02 12:29 ` vries at gcc dot gnu.org
2020-04-02 14:48 ` cvs-commit at gcc dot gnu.org
2020-04-02 14:48 ` rguenth at gcc dot gnu.org
2020-04-03 10:26 ` vries at gcc dot gnu.org
2020-04-03 11:10 ` rguenther at suse dot de
2020-04-03 12:52 ` vries at gcc dot gnu.org
2020-04-03 13:03 ` rguenther at suse dot de
2020-04-03 13:23 ` vries at gcc dot gnu.org
2020-04-03 16:43 ` vries at gcc dot gnu.org [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-94450-4-eeSsofUF3G@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).