This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


The following reply was made to PR c++/1593; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: David Carlton <carlton@kealia.com>
Cc: GNATS Filer <gdb-gnats@sources.redhat.com>
Subject: Re: c++/1593: Problem with nested namespaces
Date: Tue, 23 Mar 2004 12:46:06 -0500

 On Tue, Mar 23, 2004 at 09:31:23AM -0800, David Carlton wrote:
 > On 23 Mar 2004 17:08:02 -0000, Daniel Jacobowitz <drow@false.org> said:
 >  
 > >  The basic problem is that by explicitly providing a constructor and
 > >  destructor, you've suppressed the implicit operator=.
 > 
 > Now I'm confused.  Looking at the assembly file, you're quite right:
 > there isn't an operator= listed in the class definition.  But I think
 > there should be one - a user-defined constructor/destructor doesn't
 > suppress a compiler-defined operator=.  So, for example, if you
 > replace his main() by this:
 > 
 > int main()
 > {
 >   Foo mywrapped;
 >   Foo mywrapped2;
 > 
 >   mywrapped2 = mywrapped;
 > 
 >   return 0;
 > }
 > 
 > then you'll see operator= in the class definition in the debug info.
 > 
 > Which suggests to me that GCC (I used Red Hat's 3.2, but it must also
 > be the case for the GCC 3.3 that he used) doesn't emit identical debug
 > info for the definition of the same class in different translation
 > units.  Which really sucks, from GDB's point of view.
 
 OK, now I'm _really_ confused.  I think that I said the wrong thing in
 the first place, and then both you and I have arranged to see what we
 expected to see since.  In particular:
 
  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.  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.  I see the operator= for
 WRAPPED::Foo with both versions of main(); could you recheck?
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]