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

[Scott Johnston <scott at accom dot com>]

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