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


  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: 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).