From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6CF65388A000; Thu, 2 Apr 2020 12:29:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6CF65388A000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585830550; bh=FsDW4JZjbHfagrOWxB47u/BeGM0pp9fINsue8lUKMQc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ELY9iZqK03UwrTpUUZYCDuKciSe7Jg3iSyScZNADGoW72Zg2NwSsp9zPLEfBjfv80 xwXWJvgHtI5N9OVh2RvpBOUc90iovs120nwOLhtgKan1xRmlaBjfmXT50l4JwB8EDH Rxkoh/qbTOUJT7h1Lyubi6bTC9v31vSq00ugVcok= From: "vries at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/94450] lto abstract variable emitted as concrete decl Date: Thu, 02 Apr 2020 12:29:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: lto X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 12:29:10 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94450 --- Comment #5 from Tom de Vries --- (In reply to Richard Biener from comment #1) > I guess the more correct DWARF would be to have the 13d DIE include > DW_AT_declaration? Well, currently the debug info contains two concrete symbols, one with and = one without location information. The things that makes the latter symbol concr= ete are both the fact that it's contained in a CU (as opposed to in a PU), as w= ell as that it's imported into another CU (in fact, one could make an argument = that in fact three concrete symbols are present, but let's not go there). So, if we'd mark the one without location information as declaration we'd still ha= ve two concrete symbols. It could be pedantically argued that tagging the symbol as declaration is incorrect because there's in fact no declaration in the source that it corresponds to. That could be fixed by marking the declaration with DW_AT_artificial =3D=3D 1 (and perhaps marking the def with DW_AT_artificia= l =3D=3D 0 in order to make sure the artificial setting is not inherited, in case we go the DW_AT_specification route). Btw, the dwarf5 standard lists DW_AT_artifi= cial as applicable to DW_TAG_variable, and the dwarf4 standard doesn't. I'm not sure yet whether that reflects improved documentation or an actual change. But indeed, marking it as declaration would make the situation resemble more non-lto code (for the case where the source has indeed both a decl and def). I wonder even if the DW_AT_artificial marking itself (irrespective of a possible DW_AT_declaration) is used or could be used in gdb to fix PR gdb/25760. I'll have to mock up a gdb testsuite dwarf assembly test-case resembling the test-case and experiment a bit to see what works, and whether gdb needs changes. Anyway, the point I was trying to make is that the easiest way to make decls abstract (rather than adding stuff to the decl itself), is by making the de= cl not a top-level member of CU, in other words: declare it in a PU, and don't import it into another CU. > Then we could also stop the "abuse" of > DW_AT_abstract_origin > and instead have to use DW_AT_specification. But I'm not sure whether > DW_AT_specification allows cross CU references (technically yes but > practically) especially since there's explicit wording that > DW_AT_specification > cannot refer to type unit entities. > Using DW_AT_specification sounds cleaner, agreed. > Note I originally saw all early debug as abstract (but we're not consiste= ntly > emitting DW_AT_inline to all early function DIEs either) but that concept > doesn't apply to globals. >=20 > As you said the DW_TAG_imported_unit serve no useful purpose (I originally > thought that it would provide proper name-lookup scopes but that works > correct in other ways). And I'm fine to simply drop those (also given > consumers seem to handle references to CUs not explicitely imported just > fine). That could be done for GCC 10 already, I fear the rest needs more > testing? >=20 Yeah, I think the part of dropping the imports should be safe, and the rest should be decided once we have more info from playing with the above-mentio= ned mockup example. > Btw, thanks for sanity checking the LTO DWARF. Sure. I'm working on trying to improve gdb speed for lto executables, and in order to test gdb patches I need to regression test in lto mode, where I do= run into regressions, which need to be analyzed, and that's how I'm running into this sort of issues.=