This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/275: C++ vptr (virtual function pointer) printing
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 17 Jan 2002 18:08:01 -0000
- Subject: Re: gdb/275: C++ vptr (virtual function pointer) printing
- Reply-to: Daniel Jacobowitz <drow at mvista dot com>
The following reply was made to PR gdb/275; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: scott@accom.com
Cc: gdb-gnats@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: gdb/275: C++ vptr (virtual function pointer) printing
Date: Thu, 17 Jan 2002 13:04:10 -0500
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