Re: gdb/275: C++ vptr (virtual function table pointer) printing

[Scott Johnston <scott at accom dot com>]

The following reply was made to PR gdb/275; it has been noted by GNATS.

From: Scott Johnston <scott@accom.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-gnats@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: gdb/275: C++ vptr (virtual function table pointer) printing
Date: Thu, 17 Jan 2002 10:43:58 -0800

 Daniel Jacobowitz wrote:
 
 > On Thu, Jan 17, 2002 at 05:53:47PM -0000, scott@accom.com wrote:
 > >
 > > >Number:         275
 > > >Category:       gdb
 > > >Synopsis:       C++ vptr (virtual function pointer) printing
 > > >Confidential:   no
 > > >Severity:       serious
 > > >Priority:       medium
 > > >Responsible:    unassigned
 > > >State:          open
 > > >Class:          sw-bug
 > > >Submitter-Id:   net
 > > >Arrival-Date:   Thu Jan 17 09:58:01 PST 2002
 > > >Closed-Date:
 > > >Last-Modified:
 > > >Originator:     Scott Johnston
 > > >Release:        2002-01-16-cvs
 > > >Organization:
 > > >Environment:
 > > gcc-3.0.1, binutils-2.10, RH Linux 6.2
 > > >Description:
 > > Changes since 5.1 have improved printing of C++ classes.
 > > The most obvious thing still missing (relative to classic
 > > gdb and g++) is the printing of the virtual function pointer
 > > contained in every C++ class with virtual methods.  Either
 > > as a unique address which can be used to determine the
 > > derived class of a particular instance, or better yet, as
 > > a symbol that contains the actual name of the class.  This
 > > capability is indispensable for C++ debugging.  Thanks.
 >
 > Printing the virtual function pointer was never the right way to do
 > this; that it happened at all was an accident of the implementation.
 > It would be nice to provide a way to do it, though.
 >
 > Would a separate command be good enough for you?  How about adding it
 > to 'whatis' - and/or a flag to ptype to print the object in its derived
 > type?
 >
 > Of course, we could only do this for types with virtual methods without
 > having to add real RTTI support.  Which I might do someday.
 >
 > --
 > Daniel Jacobowitz                           Carnegie Mellon University
 > MontaVista Software                         Debian GNU/Linux Developer
 
 Daniel,
 
 I'm not sure what is "incorrect" about converting the vptr address
 to a symbol while printing the class structure (not really the virtual
 function pointer, but the pointer to the table of virtual function
 pointers).  I could live with a command that did the same, but it
 would need to handle multiple-inheritance.  As for the flag for
 printing the derived contents of an instance, I would assume
 this could be done with casting as before.
 
 But on second thought, wouldn't it be simpler (and more
 informative) to show these pointers exactly where they exist
 within the structure, like before?  What about when the bug
 your chasing overwrites the vptr?  If I can't see where it is
 within the struct, and see what its current value is, I can't
 trace that kind of memory overwrite problem.
 
 In any case, thanks for your efforts in improving gdb's support
 of C++.   Now I can see the light at the end of the tunnel :-)
 
 Scott Johnston
 http://www.ivtools.org