This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: c++/1471: [regression] ptype prints "int operator int();" with new demangler, stabs+
- 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: 28 Nov 2003 20:38:00 -0000
- Subject: Re: c++/1471: [regression] ptype prints "int operator int();" with new demangler, stabs+
- Reply-to: Daniel Jacobowitz <drow at mvista dot com>
The following reply was made to PR c++/1471; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: mec.gnu@mindspring.com
Cc: gdb-gnats@sources.redhat.com, ian@wasabisystems.com
Subject: Re: c++/1471: [regression] ptype prints "int operator int();" with new demangler, stabs+
Date: Fri, 28 Nov 2003 15:32:07 -0500
On Fri, Nov 28, 2003 at 08:13:10PM -0000, Michael Chastain wrote:
> When reading the symbol table, gdb calls the demangler to figure out whether the mangled method name is an operator name or not. gdb makes this call:
>
> // method_name_from_physname
> char *demangled_name = cplus_demangle (physname, DMGL_ANSI);
>
> The physname here is: _ZN3FoocviEv
> The old demangler returns: Foo::operator int()
> The new demangler returns: Foo::operator int
>
> In my opinion, the new demangler is correct. gdb does intentionally omit DMGL_PARAMS here and really does want the method name with no params. But if someone thinks that "Foo::operator int()" was really the correct return value than we could file a bug against the demangler.
Yes, I agree with your analysis.
I'm working on something else in C++ support right now
(canonicalization, as I discussed with Ian); then I'll take a look.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer