This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Proper test status if gdb test detects a g++ bug?
- To: gdb at sources dot redhat dot com
- Subject: Re: Proper test status if gdb test detects a g++ bug?
- From: Michael Elizabeth Chastain <chastain at cygnus dot com>
- Date: Sun, 4 Feb 2001 17:50:12 -0800
Okay, here's my understanding:
Sourceware cvs gdb has two separate g++ name demanglers.
The two separate name demanglers have some subtle differences in their
output formats. Specifically:
old demangler new demangler
"operator, " "operator,"
"char *" "char*"
"int *" "int*"
"long *" "long*"
"void *" "void*"
"foo &" "foo&"
"unsigned int" "unsigned"
"void" ""
It would be nice if the new demangler changed some of its output to be
exactly compatible with the old demangler. In particular, I don't like
the change from "unsigned int" -> "unsigned". But the demangler might
have good reasons for some of the other changes.
Several gdb.c++ test scripts do not handle the new format yet. I am
upgrading these one at a time. Right now I am on gdb.c++/cplusfuncs.exp.
On top of the format differences, the two demanglers produce substantially
different output on some complicated functions. Here's the specific
test code:
// gdb.c++/cplusfuncs.exp
typedef int (*PFl_i)(long);
typedef PFl_i (*PFPc_PFl_i)(char *);
int hairyfunc5 (PFPc_PFl_i arg) { arg = 0; return 0; }
When I use an old g++ compiler, gdb uses its old demangler:
print &'hairyfunc5'^M
$78 = (int (*)(PFPc_PFl_i)) 0x8048c00 <hairyfunc5(int (*(*)(char *))(long))>
When I use cvs g++, gdb uses its new demangler:
print &'hairyfunc5'^M
$78 = (int (*)(PFPc_PFl_i)) 0x8049120 <hairyfunc5(int (*)(long) (*)(char*))>
According to Alexander Oliva, the first form is correct. My reading
of K & R 2nd edition agrees with him. See section 5.12, "Complicated
Declarations".
Now there are two possibilities. Perhaps cvs g++ emits bad type
information, or perhaps cvs g++ emits good type information and gdb
mis-interprets it.
Here is the stab from the generated assembly code:
.stabs "_Z10hairyfunc5PFPFilEPcE:F(0,1)",36,0,183,_Z10hairyfunc5PFPFilEPcE
This says that hairyfunc5 is:
function with
return type
(0,1) = int
arg list
pointer to function with
return type
pointer to function with return type int arg list long
arg list
pointer to char
This is correct. I hand checked the stabs for all the hairyfunc's,
and all of them are correct.
Therefore:
(1) cvs gcc emits correct stabs for the hairyfunc's.
cvs gdb demangles the names improperly.
(2) I will file a gnats report against gdb with this analysis.
(3) In the test script, I will list the correct form for the hairyfuncs.
The tests will PASS when when using g++ 2.95, and will FAIL
when using cvs g++.
Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"