This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
c++/1471: [regression] ptype prints "int operator int();" with new demangler, stabs+
- From: mec dot gnu at mindspring dot com
- To: gdb-gnats at sources dot redhat dot com
- Cc: ian at wasabisystems dot com
- Date: 28 Nov 2003 20:13:10 -0000
- Subject: c++/1471: [regression] ptype prints "int operator int();" with new demangler, stabs+
- Reply-to: mec dot gnu at mindspring dot com
>Number: 1471
>Category: c++
>Synopsis: [regression] ptype prints "int operator int();" with new demangler, stabs+
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Nov 28 20:18:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: mec.gnu@mindspring.com
>Release: gdb HEAD 2003-11-26 07:42:46 UTC
>Organization:
>Environment:
target = native, host = i686-pc-linux-gnu, osversion = red-hat-8.0
gdb = HEAD 2003-11-26 07:42:46 UTC
gcc = 3.3.2
binutils = 2.14
glibc = 2.2.93-5-rh
gformat = stabs+
glevel = 2
>Description:
Here is an exceprt from gdb.log:
(gdb) ptype class Foo
...
int operator int ();
...
This should be "operator int ();" of course.
This is a regression from gdb 6.0. It happens with gcc v3 -gstabs+.
The problem happens with the new demangler, but it is not a demangler bug -- it is a gdb bug about parsing the demangler output.
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.
Getting back to the story ... gdb takes this return value and tries to extract the method name by calling find_last_component. find_last_component looks for the parentheses to throw away the parameters, doesn't find any parentheses, and punts.
Later on this manifests in the C/C++ type printer when gdb decides to treat "operator int" as a normal function and print a return type in front of it.
>How-To-Repeat:
Run the test script gdb.cp/classes.exp with gcc 3.3.2 -gstabs+ and look at the output of "ptype class Foo". Note the line that says "int operator int();".
The test script actually accepts this output as "obsolete gcc/gdb", but the output is incorrect.
>Fix:
Upgrade find_last_component and related functions in cp-support.c to work properly with the new demangler (which is working properly).
>Release-Note:
>Audit-Trail:
>Unformatted: