This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: c++/1593: Problem with nested namespaces
- From: David Carlton <carlton at kealia dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 23 Mar 2004 19:08:01 -0000
- Subject: Re: c++/1593: Problem with nested namespaces
- Reply-to: David Carlton <carlton at kealia dot com>
The following reply was made to PR c++/1593; it has been noted by GNATS.
From: David Carlton <carlton@kealia.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: GNATS Filer <gdb-gnats@sources.redhat.com>
Subject: Re: c++/1593: Problem with nested namespaces
Date: Tue, 23 Mar 2004 11:03:12 -0800
On 23 Mar 2004 17:48:01 -0000, Daniel Jacobowitz <drow@false.org> said:
> GDB 6.0 goes into an infinite loop
> GDB 6.1 works as described in the report
> $1 = {<> = {<No data fields>}, <No data fields>}
> (gdb) ptype mywrapped
> type = class WRAPPED::Foo : public Foo {
> public:
> void Foo(void);
> ~Foo(int);
> }
> So it's the base type whose name we got wrong.
> BASE::Foo in wrapper_object.o has an operator= and we infer its
> name. BASE::Foo in wrapper.o is just a declaration.
That's what I was missing - I had just assumed that, since there were
methods mentioned in the debug info for BASE::Foo, that it was a
definition, but it is in fact a declaration. And it's fine for
declarations to contain different amounts of information in different
translation units, of course.
> So it has nothing from which to infer its name, and we lose.
> If we had DW_TAG_namespace, we would still get the right results.
That should be the case. Though, unfortunately, it isn't so simple;
when I used my hacked GCC 3.2 that generates DW_TAG_namespace, things
work fine:
(gdb) p mywrapped
$1 = {<BASE::Foo> = {_vptr.Foo = 0x80496c0}, <No data fields>}
But when I use "g++ (GCC) 3.5.0 20040119", we're back to our old
behavior:
(gdb) p mywrapped
$1 = {<> = {<No data fields>}, <No data fields>}
I'll have to look into that further.
(Hmm: should determine_class_name restore processing_current_prefix if
it has to change it? Probably, but looking at the callers, we're
currently safe, so that's not the issue here.)