public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dodji at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location Date: Fri, 26 Feb 2010 12:59:00 -0000 [thread overview] Message-ID: <20100226125857.32201.qmail@sourceware.org> (raw) In-Reply-To: <bug-37237-3264@http.gcc.gnu.org/bugzilla/> ------- Comment #5 from dodji at gcc dot gnu dot org 2010-02-26 12:58 ------- Created an attachment (id=19968) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19968&action=view) Candidate patch Here is what I think is happening, at least on gcc 4.5. A/ The deleting dtor's DIE *is* being generated but: 1/ not as a member of struct A's DIE 2/ no DW_AT_vtable_elem_location was being generated for it. But there is (and I believe, rightfully so) a DW_AT_abstract_origin attribute pointing back to the abstract dtor that is part of the struct A's DIE members. B/ The complete destructor was not being generated. That was because the complete dtor is not only a clone of the abstract destructor, but also an *alias* (i.e it shares the same body) of the base dtor (the not-in charge one). Note that the base dtor is not part of the vtable, but the complete dtor is. So the complete dtor is an alias. But for a reason, cgraph forgets to emit debug info for aliases. It emits debug info only for the *target* of an alias. Independently of this, and after chatting with Tom Tromey and Jason Merrill, it looks like we ought to generate debug info for all variants of destructors, even if only the abstract dtor is part of the members DIEs of the struct. The most natural way of doing this would be to stay compatible with what's done already and fix issues A.1/ and B/ described above. The debugger would be able to tell that a given function is a destructor variant if it has a DW_AT_abstract_origin pointing back to the abstract destructor of the type. Now a problem remains which is how to let the debugger know that a given destructor is either a base, complete or deleting one. It looks like a new attribute (GNU extension) would address that issue. The attached patch fixes A.1/ and B/ but doesn't add the new attribute yet. I wanted to have your input before. I am cc-ing Jason too, as I notice he is not in the CC list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
next prev parent reply other threads:[~2010-02-26 12:59 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-08-25 19:54 [Bug debug/37237] New: " drow at gcc dot gnu dot org 2010-02-11 18:44 ` [Bug debug/37237] " dodji at gcc dot gnu dot org 2010-02-12 15:48 ` dodji at gcc dot gnu dot org 2010-02-12 15:52 ` drow at gcc dot gnu dot org 2010-02-21 16:47 ` dodji at gcc dot gnu dot org 2010-02-23 16:56 ` tromey at gcc dot gnu dot org 2010-02-26 12:59 ` dodji at gcc dot gnu dot org [this message] 2010-02-26 20:48 ` jason at gcc dot gnu dot org [not found] <bug-37237-4@http.gcc.gnu.org/bugzilla/> 2011-05-24 13:51 ` tromey at gcc dot gnu.org 2012-07-12 18:34 ` tromey at gcc dot gnu.org 2012-07-13 17:15 ` tromey at gcc dot gnu.org 2013-01-31 19:32 ` jason at gcc dot gnu.org 2013-02-18 15:21 ` tromey at gcc dot gnu.org 2013-02-26 4:35 ` jason at gcc dot gnu.org 2013-11-14 16:56 ` tromey 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=20100226125857.32201.qmail@sourceware.org \ --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).