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]

c++/1471: [regression] ptype prints "int operator int();" with new demangler, stabs+


>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:


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