This is the mail archive of the
mailing list for the GDB project.
Re: gdb/275: C++ vptr (virtual function pointer) printing
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: scott at accom dot com
- Cc: gdb-gnats at sources dot redhat dot com, gdb at sources dot redhat dot com
- Date: Thu, 17 Jan 2002 13:04:10 -0500
- Subject: Re: gdb/275: C++ vptr (virtual function pointer) printing
- References: <firstname.lastname@example.org>
On Thu, Jan 17, 2002 at 05:53:47PM -0000, email@example.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
> >Originator: Scott Johnston
> >Release: 2002-01-16-cvs
> gcc-3.0.1, binutils-2.10, RH Linux 6.2
> 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
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