------- 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

Reply via email to