public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
       [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
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: tromey at gcc dot gnu.org @ 2011-05-24 13:51 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

--- Comment #7 from Tom Tromey <tromey at gcc dot gnu.org> 2011-05-24 13:10:13 UTC ---
*** Bug 49131 has been marked as a duplicate of this bug. ***


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
       [not found] <bug-37237-4@http.gcc.gnu.org/bugzilla/>
  2011-05-24 13:51 ` [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location 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
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: tromey at gcc dot gnu.org @ 2012-07-12 18:34 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

--- Comment #8 from Tom Tromey <tromey at gcc dot gnu.org> 2012-07-12 18:34:08 UTC ---
I'd like to ping this again.

I've been working on adding support for new and delete to gdb.
The missing debuginfo here is a barrier to this.

I think gdb would generally like to call the deleting destructor
when it is available.  Right now there is no way to find this
destructor from the debuginfo.

I agree this would require a DWARF extension.  I think something
like DW_AT_destructor with values DW_DESTRUCTOR_complete_object,
DW_DESTRUCTOR_deleting, and DW_DESTRUCTOR_base_object.
I can file a bug on dwarfstd.org if you think this makes sense.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
       [not found] <bug-37237-4@http.gcc.gnu.org/bugzilla/>
  2011-05-24 13:51 ` [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location 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
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: tromey at gcc dot gnu.org @ 2012-07-13 17:15 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

--- Comment #9 from Tom Tromey <tromey at gcc dot gnu.org> 2012-07-13 17:14:38 UTC ---
Likewise there isn't a super way to find out which
constructor is in-charge.  The only way I could come up
with is to look at the linkage name; but this requires
excessive knowledge of the mangling scheme.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
       [not found] <bug-37237-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  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
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu.org @ 2013-01-31 19:32 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> 2013-01-31 19:32:35 UTC ---
I don't think such an attribute belongs in the DWARF standard, since this is
very much an internal detail of the ABI; another ABI might have just a single
destructor with magic arguments, like the old G++ ABI.

You need to know a lot about the destructor ABI as it is; looking for D0/D1
doesn't seem like a major additional burden to me.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
       [not found] <bug-37237-4@http.gcc.gnu.org/bugzilla/>
                   ` (3 preceding siblings ...)
  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
  6 siblings, 0 replies; 14+ messages in thread
From: tromey at gcc dot gnu.org @ 2013-02-18 15:21 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

--- Comment #11 from Tom Tromey <tromey at gcc dot gnu.org> 2013-02-18 15:20:56 UTC ---
(In reply to comment #10)
> I don't think such an attribute belongs in the DWARF standard, since this is
> very much an internal detail of the ABI; another ABI might have just a single
> destructor with magic arguments, like the old G++ ABI.
> 
> You need to know a lot about the destructor ABI as it is; looking for D0/D1
> doesn't seem like a major additional burden to me.

With git master I actually see multiple destructors now:

 <1><be>: Abbrev Number: 15 (DW_TAG_subprogram)
    <bf>   DW_AT_abstract_origin: <0x93>        
    <c3>   DW_AT_linkage_name: (indirect string, offset: 0x10): _ZN1AD2Ev       
    <c7>   DW_AT_low_pc      : 0x0      
    <cf>   DW_AT_high_pc     : 0x39 0x0 
    <d7>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_cfa)
    <d9>   DW_AT_object_pointer: <0xe1> 
    <dd>   DW_AT_GNU_all_tail_call_sites: 1     
    <dd>   DW_AT_sibling     : <0xea>   
[...]
 <1><ea>: Abbrev Number: 17 (DW_TAG_subprogram)
    <eb>   DW_AT_abstract_origin: <0x93>        
    <ef>   DW_AT_linkage_name: (indirect string, offset: 0x3e): _ZN1AD0Ev       
    <f3>   DW_AT_low_pc      : 0x3a     
    <fb>   DW_AT_high_pc     : 0x26 0x0 
    <103>   DW_AT_frame_base  : 1 byte block: 9c        (DW_OP_call_frame_cfa)
    <105>   DW_AT_object_pointer: <0x109>       
    <109>   DW_AT_GNU_all_tail_call_sites: 1    


What I'd like to know is what is guaranteed.
Previously gcc didn't emit the linkage name for any destructor -- but
this would make the proposed solution much harder to implement (gdb
would have to implement name mangling...).
So I suppose I'd like a guarantee that the destructor will be emitted
with at least one linkage name.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
       [not found] <bug-37237-4@http.gcc.gnu.org/bugzilla/>
                   ` (4 preceding siblings ...)
  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
  6 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu.org @ 2013-02-26  4:35 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> 2013-02-26 04:35:16 UTC ---
(In reply to comment #11)
> What I'd like to know is what is guaranteed.
> Previously gcc didn't emit the linkage name for any destructor -- but
> this would make the proposed solution much harder to implement (gdb
> would have to implement name mangling...).
> So I suppose I'd like a guarantee that the destructor will be emitted
> with at least one linkage name.

I would guess that the earlier situation was a bug whereby we were only
emitting code for the cloned function, not the clones, and we don't give a
linkage name for an abstract function.  In any case, it was a bug, and we
should continue to emit linkage names like we do for any other function.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
       [not found] <bug-37237-4@http.gcc.gnu.org/bugzilla/>
                   ` (5 preceding siblings ...)
  2013-02-26  4:35 ` jason at gcc dot gnu.org
@ 2013-11-14 16:56 ` tromey at gcc dot gnu.org
  6 siblings, 0 replies; 14+ messages in thread
From: tromey at gcc dot gnu.org @ 2013-11-14 16:56 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

--- Comment #13 from Tom Tromey <tromey at gcc dot gnu.org> ---
I was debugging this today:
https://sourceware.org/bugzilla/show_bug.cgi?id=15975

... and ran across this PR again.
GCC is still emitting a virtual destructor with no indication of
its vtable element location:

 <2><37c>: Abbrev Number: 18 (DW_TAG_subprogram)
    <37d>   DW_AT_external    : 1    
    <37d>   DW_AT_name        : ~B    
    <380>   DW_AT_decl_file   : 1    
    <381>   DW_AT_decl_line   : 23    
    <382>   DW_AT_virtuality  : 1    (virtual)
    <383>   DW_AT_containing_type: <0x33d>    
    <387>   DW_AT_declaration : 1    
    <387>   DW_AT_object_pointer: <0x38b>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
  2008-08-25 19:54 [Bug debug/37237] New: " drow at gcc dot gnu dot org
                   ` (5 preceding siblings ...)
  2010-02-26 12:59 ` dodji at gcc dot gnu dot org
@ 2010-02-26 20:48 ` jason at gcc dot gnu dot org
  6 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu dot org @ 2010-02-26 20:48 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from jason at gcc dot gnu dot org  2010-02-26 20:47 -------
The patch looks good.  I don't think we want to add an extension for this; if
we need an additional feature, it should be standardized.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
  2008-08-25 19:54 [Bug debug/37237] New: " drow at gcc dot gnu dot org
                   ` (4 preceding siblings ...)
  2010-02-23 16:56 ` tromey at gcc dot gnu dot org
@ 2010-02-26 12:59 ` dodji at gcc dot gnu dot org
  2010-02-26 20:48 ` jason at gcc dot gnu dot org
  6 siblings, 0 replies; 14+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-02-26 12:59 UTC (permalink / raw)
  To: gcc-bugs



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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
  2008-08-25 19:54 [Bug debug/37237] New: " drow at gcc dot gnu dot org
                   ` (3 preceding siblings ...)
  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
  2010-02-26 20:48 ` jason at gcc dot gnu dot org
  6 siblings, 0 replies; 14+ messages in thread
From: tromey at gcc dot gnu dot org @ 2010-02-23 16:56 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from tromey at gcc dot gnu dot org  2010-02-23 16:55 -------
It seems to me that, by analogy with constructors, we would want debuginfo
for all the destructors, so that "break X::~X" would put breakpoints in all
the clones.
Then we would need additional information to distinguish the destructors
so that we can implement "delete x".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
  2008-08-25 19:54 [Bug debug/37237] New: " drow at gcc dot gnu dot org
                   ` (2 preceding siblings ...)
  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
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-02-21 16:47 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from dodji at gcc dot gnu dot org  2010-02-21 16:47 -------
Okay Daniel, your POV makes sense to me. Thank you.
I am preparing a patch.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-02-11 18:44:13         |2010-02-21 16:47:24
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
  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
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: drow at gcc dot gnu dot org @ 2010-02-12 15:52 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from drow at gcc dot gnu dot org  2010-02-12 15:52 -------
The type of the class only contains one destructor.  If you have to pick one
for a debugger to call, in-charge makes the most sense.  For other debugger
purposes they all make equal sense (or nonsense).

If you want to represent all three in the debug info, then not only do we need
to know that they are clones of the same function, we also need to know which
one is the in-charge versus not-in-charge versus deleting destructor to call
the right one for debugger implementation of the delete statement.

I'm pretty sure that would require new debug info extensions and new debugger
support.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
  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
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-02-12 15:48 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from dodji at gcc dot gnu dot org  2010-02-12 15:48 -------
There are actually up to three destructors:

- an in-charge one (or complete-object one)
- a not-in-charge one
- a deleting in-charge one

The three of them are useful in different ways and in different circumstances. 

The destructor being represented in the DWARF output right now is the
"abstract" one, i.e. the one that got cloned (at most) 3 times into the 3
different types of destructors. It doesn't have any DW_AT_vtable_elem_location
precisely because that abstract version of destructor is not present in the
vtable. The destructors present in vtable are the clones. We do not output
those in the debug info today.

Daniel, why would you prefer having the DW_AT_vtable_elem_location only for the
in-charge one?

We could chose to have all three of them being represented in the DWARF output
but then there should be a way to say that they are different concrete
instances of the abstract ~A destructor. Maybe by using the extension
DW_AT_MIPS_clone_origin to make it point to the abstract constructor/destructor
instance which a particular constructor/destructor clone implements?


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dodji at gcc dot gnu dot org
         AssignedTo|dodji at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
  2008-08-25 19:54 [Bug debug/37237] New: " drow at gcc dot gnu dot org
@ 2010-02-11 18:44 ` dodji at gcc dot gnu dot org
  2010-02-12 15:48 ` dodji at gcc dot gnu dot org
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-02-11 18:44 UTC (permalink / raw)
  To: gcc-bugs



-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-02-11 18:44:13
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2013-11-14 16:56 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-37237-4@http.gcc.gnu.org/bugzilla/>
2011-05-24 13:51 ` [Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location 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
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
2010-02-26 20:48 ` jason at gcc dot gnu dot org

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