From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9FF3A3858005; Wed, 28 Oct 2020 09:16:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9FF3A3858005 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments Date: Wed, 28 Oct 2020 09:16:28 +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: 11.0 X-Bugzilla-Keywords: wrong-debug X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Wed, 28 Oct 2020 09:16:28 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97599 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu.org, | |mark at gcc dot gnu.org, | |palves at redhat dot com --- Comment #3 from Jakub Jelinek --- So, let's first discuss how we want to represent these in DWARF, I've added further folks on CC, thoughts on that? If the function is the same rather than some clone with possibly changed calling convention, does your reading of DWARF suggest that each DW_TAG_subprogram should have its own DW_TAG_unspecified_parameters child, = or e.g. DW_AT_calling_convention attribute, or is that something that can be inherited through DW_AT_abstract_origin and only overridden if different fr= om the abstract origin? Then there is the question what to do with function clones, which, while can have different arguments and calling convention, but otherwise they still represent the whole function. And finally, the question of just outlined regions of functions, whether it= is the outlined part of partial inlining, OpenMP/OpenACC etc. outlined regions etc. At least for this third set I think we really want some attribute that says they are partial (e.g. implementations should expect their start to be the start of the function) and with DW_AT_abstract_origin pointing to something more useful (e.g. the DW_TAG_lexical_block they are representing?). As for the implementation of this patch if DW_TAG_unspecified_parameters an= d/or DW_AT_calling_convention aren't inherited through DW_AT_abstract_origin by consumers, I think rather than what I'm doing in the above patch for LTO we could immediately after old_die =3D lookup_die (decl); remember for in_lto_= p if old_die->die_child was NULL, that would stand for a freshly created DIE and then could be used as if (subr_die !=3D old_die || old_die_was_empty) to de= cide whether to add DW_TAG_unspecified_parameters or not.=