Re: c++/1593: Problem with nested namespaces

[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.)