This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/488: vtable, RTTI, and namespaces don't work together
- 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: 16 Apr 2002 00:28:01 -0000
- Subject: Re: gdb/488: vtable, RTTI, and namespaces don't work together
- Reply-to: Daniel Jacobowitz <drow at mvista dot com>
The following reply was made to PR gdb/488; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: jelenz@students.wisc.edu
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/488: vtable, RTTI, and namespaces don't work together
Date: Mon, 15 Apr 2002 20:19:20 -0400
On Mon, Apr 15, 2002 at 10:09:04PM -0000, jelenz@students.wisc.edu wrote:
>
> >Number: 488
> >Category: gdb
> >Synopsis: vtable, RTTI, and namespaces don't work together
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: unassigned
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Mon Apr 15 15:18:02 PDT 2002
> >Closed-Date:
> >Last-Modified:
> >Originator: John Lenz
> >Release: latest CVS
> >Organization:
> >Environment:
>
> >Description:
> When debuging that simple program attached below, the debug session when a breakpoint is added on line 27
> ...
> (gdb) p bar
> $1 = (Bar *) 0x8049a00
> (gdb) p *bar
> can't find class named `Name::Bar`, as given by C++ RTTI
>
> If you comment out the virtual function in the foo class, it prints out the class fine. Also, removing the namespace and leaving the virtual function in the class also compiles and prints the class as expected. A dynamic_cast from a Foo to a Bar works so I believe that the compiler finds the Name::Bar type in the RTTI and runs as expected.
>
> I am compiling with gcc version 3.0.4. When this test program is compiled with gcc 2.95.4, it debugs and prints fine.
Yes, namespaces are badly supported. In particular types inside of
namespaces. It is unlikely to ever work with STABS (-g on 3.0.x); it
should be fixed for DWARF-2 (-gdwarf-2, or -g on 3.1) in the "near
future".
Thanks for the simple testcase.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer