This is the mail archive of the gdb@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]

Re: Proper test status if gdb test detects a g++ bug?


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"

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