public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/97599] New: [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments Date: Tue, 27 Oct 2020 17:09:21 +0000 [thread overview] Message-ID: <bug-97599-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97599 Bug ID: 97599 Summary: [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: aldyh at gcc dot gnu.org, woodard at redhat dot com Depends on: 71855 Target Milestone: --- Target: x86-64-Linux +++ This bug was initially created as a clone of Bug #71855 +++ Since PR71855, we emit bad debug info e.g. for #include <stdarg.h> static __attribute__((noinline)) int foo (int unused, int args, ...) { va_list ap; int ret = 0; va_start (ap, args); if (args) ret = va_arg (ap, int); va_end (ap); return ret; } int bar (int x) { return foo (0, 0) + foo (0, 1, 1) + foo (0, 1, 3) + foo (0, 0) + foo (0, 0, 4); } Also, with LTO: #include <stdarg.h> void foo (int args, ...) { va_list ap; va_start (ap, args); va_end (ap); } gcc -shared -g -fpic -flto test.c As written in https://bugzilla.redhat.com/show_bug.cgi?id=1891787 , it seems it isn't enough to rely on the DW_TAG_unspecified_parameters DIE being present among the abstract origin DIE of the DW_TAG_subprogram's children; the debug info consumer can't know if the clone of that original function is really still variadic, or if e.g. the variadic-ness has been removed. For the non-LTO case, it is I think fairly easy to do, subr_die != old_die should be true if it is a fresh new DIE, but I'm afraid for in_lto_p we don't really know easily if it is a fresh new DIE or not. As we have nothing to lookup in the hash tables to find out cheaply if it is there or not already, the following is a painful way of doing that. Thoughts on that? --- gcc/dwarf2out.c.jj 2020-10-26 10:53:56.000000000 +0100 +++ gcc/dwarf2out.c 2020-10-27 17:56:07.249711468 +0100 @@ -23365,6 +23365,35 @@ gen_subprogram_die (tree decl, dw_die_re else if (DECL_INITIAL (decl) == NULL_TREE) gen_unspecified_parameters_die (decl, subr_die); } + else if (prototype_p (TREE_TYPE (decl)) + && stdarg_p (TREE_TYPE (decl))) + { + /* Emit DW_TAG_unspecified_parameters even in late DWARF, + but ensure to do it only when it isn't present already. + If subr_die != old_die, this is a new DIE to which it + should be added, otherwise if in_lto_p, we don't really + know if it is a freshly created one or something older, + so look it up. */ + bool emit = subr_die != old_die; + if (!emit && in_lto_p) + { + dw_die_ref c; + emit = true; + FOR_EACH_CHILD (subr_die, c, + do + { + if (c->die_tag + == DW_TAG_unspecified_parameters) + { + emit = false; + break; + } + } + while (0)); + } + if (emit) + gen_unspecified_parameters_die (decl, subr_die); + } } if (subr_die != old_die) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855 [Bug 71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments
next reply other threads:[~2020-10-27 17:09 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-27 17:09 jakub at gcc dot gnu.org [this message] 2020-10-27 17:09 ` [Bug debug/97599] " jakub at gcc dot gnu.org 2020-10-28 7:41 ` rguenth at gcc dot gnu.org 2020-10-28 7:43 ` rguenth at gcc dot gnu.org 2020-10-28 9:10 ` rguenth at gcc dot gnu.org 2020-10-28 9:16 ` jakub at gcc dot gnu.org 2020-10-28 9:58 ` jakub at gcc dot gnu.org 2020-10-28 10:00 ` rguenth at gcc dot gnu.org 2020-11-14 8:15 ` cvs-commit at gcc dot gnu.org 2020-11-25 11:56 ` cvs-commit at gcc dot gnu.org 2020-11-25 17:18 ` [Bug debug/97599] [8/9 " jakub at gcc dot gnu.org 2021-04-20 23:30 ` cvs-commit at gcc dot gnu.org 2021-04-22 16:48 ` cvs-commit at gcc dot gnu.org 2021-04-22 17:07 ` jakub at gcc dot gnu.org
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-97599-4@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: linkBe 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).