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: Daniel Jacobowitz <drow at false dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 23 Mar 2004 17:48:01 -0000
- Subject: Re: c++/1593: Problem with nested namespaces
- Reply-to: Daniel Jacobowitz <drow at false dot org>
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