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

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

[Michael Elizabeth Chastain]

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"

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

[Alexandre Oliva]

On Feb  4, 2001, Michael Elizabeth Chastain <chastain@cygnus.com> wrote:

> (1) cvs gcc emits correct stabs for the hairyfunc's.
>     cvs gdb demangles the names improperly.

GDB is probably using the demangler from libiberty, that is the same
demangler used by c++filt.  By fixing libiberty, we'd be fixing GDB,
c++filt and a few other tools in binutils that do their own
demangling.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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

[Alexandre Oliva]

On Feb  5, 2001, Andrew Cagney <ac131313@cygnus.com> wrote:

> According to src/MAINTAINERS GCC look after libiberty.

AFAIK, DJ was the sole maintainer of libiberty.  It's possible that,
for whatever reason, he decided the master copy of libiberty was that
in the GCC CVS repo, and added this note to src/MAINTAINERS to make
sure the copy in the src repo isn't modified without having the change
submitted to GCC.

It would be *so* nice to have a unified tree... :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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

[Andrew Cagney]

Alexandre Oliva wrote:
> 
> On Feb  5, 2001, Andrew Cagney <ac131313@cygnus.com> wrote:
> 
> > Michael, I'd file a corresponding bug report in the GCC database. GCC
> > and not GDB maintains the demangler.
> 
> Are you sure?  The demangler is part of libiberty, not GCC in
> particular.  In fact, GCC itself has no need for the demangler :-) Of
> course, it'd better be kept in sync with whatever mangling GCC uses,
> but I don't think it's really maintained as part of GCC.  Not that a
> bug in the GCC bug database would be a bad idea, but you risk getting
> this kind of answer and having the bug report closed :-)

I'm not sure :-)

According to src/MAINTAINERS GCC look after libiberty.  If GCC disclaim
ownership for the demangler then I'd better clarify the comment in
src/MAINTAINERS.

	Andrew

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

[Michael Elizabeth Chastain]

ac> Michael, I'd file a corresponding bug report in the GCC database. GCC
ac> and not GDB maintains the demangler.

Sounds good.  I notice that libiberty has a testsuite:

  libiberty/testsuite/demangle-expected

The hairyfunc lines will look dandy in there.

  --format=gnu
  _Z10hairyfunc5PFPFilEPcE
  hairyfunc5(int (*(*)($dm_type_char_star))(long))

It's too much to do on the fly though.  I'll do it in my next weekend
session.

Michael

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

[Alexandre Oliva]

On Feb  5, 2001, Andrew Cagney <ac131313@cygnus.com> wrote:

> Michael, I'd file a corresponding bug report in the GCC database. GCC
> and not GDB maintains the demangler.

Are you sure?  The demangler is part of libiberty, not GCC in
particular.  In fact, GCC itself has no need for the demangler :-) Of
course, it'd better be kept in sync with whatever mangling GCC uses,
but I don't think it's really maintained as part of GCC.  Not that a
bug in the GCC bug database would be a bad idea, but you risk getting
this kind of answer and having the bug report closed :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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

[Andrew Cagney]

Michael Elizabeth Chastain wrote:
> 
> GDB is indeed calling cplus_demangle_v3 from libiberty/cp-demangle.c.
> 
> If anyone wants to work on this, it's gnats-gdb bug gdb/19.

Michael, I'd file a corresponding bug report in the GCC database. GCC
and not GDB maintains the demangler.

	Andrew

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

[Michael Elizabeth Chastain]

GDB is indeed calling cplus_demangle_v3 from libiberty/cp-demangle.c.

If anyone wants to work on this, it's gnats-gdb bug gdb/19.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

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

[Michael Elizabeth Chastain]

Hi Alexandre,

> Nope.  It has the form `T = RET (*PTR)(arglist)'.  In this case
> `PTR = RET2 (*PTR2)(arglist)'.  Substituting PTR in T, you'll get [1],
> not [2].
> 
> int hairyfunc5 (PFPc_PFl_i arg) =
> int hairyfunc5 (PFl_i (*arg)(char *)) =
> int hairyfunc5 (int (*(*arg)(char *))(long))

Oh.

I re-read Kernighan and Ritchie, "Complicated Declarations", and your
interpretation is right, and my interpretation is wrong.

I will change my test script and file bug reports accordingly.

Michael

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

[Andrew Cagney]

Michael Elizabeth Chastain wrote:
> 
> Andrew Cagney writes:
> > That is more or less the definition of XFAIL.  You'll need to figure out
> > a way of only marking that test as XFAIL for that specific compiler.
> 
> The test script doesn't really know what version the compiler is.
> It probes for specific strings in response to its tests, not an overall
> version string.  That's how it distinguishes between:
> 
>   "foo&" versus "foo &"
>   "char*" versus "char *"
>   "unsigned" versus "unsigned int"
>   "" versus "void"
> 
> In the hairyfunc tests, I can PASS on one specific string, XFAIL on
> another specific string, and FAIL on everything else.  Is that acceptable?

To me personally, that sounds wrong.  I would have thought that a test
proper could only PASS or FAIL.  Decisions that the system is broken
being kept separate vis:

	if necessary setup xfail
	perform the test

People have talked about ripping out XFAIL and moving that information
to a separate database.  If tests start to contain implicit decisions to
XFAIL then that operation is going to be very hard.

enjoy,
	Andrew

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

[Michael Elizabeth Chastain]

Andrew Cagney writes:
> That is more or less the definition of XFAIL.  You'll need to figure out
> a way of only marking that test as XFAIL for that specific compiler.

The test script doesn't really know what version the compiler is.
It probes for specific strings in response to its tests, not an overall
version string.  That's how it distinguishes between:

  "foo&" versus "foo &"
  "char*" versus "char *"
  "unsigned" versus "unsigned int"
  "" versus "void"

In the hairyfunc tests, I can PASS on one specific string, XFAIL on
another specific string, and FAIL on everything else.  Is that acceptable?

Now I have to understand Alexander's mesage about what the right strings
actually *are*.  Ow, these hairy types are giving me a headache.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

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

[Andrew Cagney]

> Alternative #2A is to treat a known bug in an external component as
> an XFAIL.  If I just use "setup_xfail", then the test will give XPASS
> when the user has g++ 3.0 (g++ 3.0 fixed this bug).  I am lukewarm about
> this but it's simple to code.

That is more or less the definition of XFAIL.  You'll need to figure out
a way of only marking that test as XFAIL for that specific compiler.

Enjoy,
	Andrew

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

[Alexandre Oliva]

On Feb  4, 2001, Michael Elizabeth Chastain <chastain@cygnus.com> wrote:

>   [1] print_addr_of "hairyfunc5(int (*(*)(char *))(long))"

>   [2] print_addr_of "hairyfunc5(int (*)(long) (*)(char *))"

> The argument type string comes from g++ stabs info.

Huh?  All I see here is a demangler error.  [1] is correct, but the
demangler is incorrectly printing [2].

> P. S.  Here is a brief explanation why the arg type is incorrect
>        as written.   A pointer-to-function always has the following type:
>        "returntype (*)(arglist)".

Nope.  It has the form `T = RET (*PTR)(arglist)'.  In this case
`PTR = RET2 (*PTR2)(arglist)'.  Substituting PTR in T, you'll get [1],
not [2].

int hairyfunc5 (PFPc_PFl_i arg) =
int hairyfunc5 (PFl_i (*arg)(char *)) =
int hairyfunc5 (int (*(*arg)(char *))(long))

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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

[Eli Zaretskii]

On Sun, 4 Feb 2001, Michael Elizabeth Chastain wrote:

> So, if I use the correct test [2], then the test will fail when the
> tester uses a g++ 2.95 compiler.  Personally I like it this way.  g++
> 2.95 has this bug and I think a gdb test script should issue a FAIL,
> even though the bug is in a different component.  That's alternative #1.

IMHO, fail the test, but print a message about it being a known bug with 
GCC 2.95.

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

[Michael Elizabeth Chastain]

I'm working on testsuite/gdb.c++/cplusfuncs.exp in an effort to make
it work well with g++ 2.95 and g++ 3.0.

For reference, my configuration is Red Hat Linux 7 native.

I'm having a problem with this test:

  [1] print_addr_of "hairyfunc5(int (*(*)(char *))(long))"

The problem is that this argument type is incorrect.  The test with the
corect argument type would be:

  [2] print_addr_of "hairyfunc5(int (*)(long) (*)(char *))"

The argument type string comes from g++ stabs info.

So, if I use the correct test [2], then the test will fail when the
tester uses a g++ 2.95 compiler.  Personally I like it this way.  g++
2.95 has this bug and I think a gdb test script should issue a FAIL,
even though the bug is in a different component.  That's alternative #1.

Alternative #2A is to treat a known bug in an external component as
an XFAIL.  If I just use "setup_xfail", then the test will give XPASS
when the user has g++ 3.0 (g++ 3.0 fixed this bug).  I am lukewarm about
this but it's simple to code.

Alternative #2B is to probe the target compiler some more and issue a
PASS for the correct output, an XFAIL if the output is the known bad
string from a known bad compiler, and a FAIL otherwise.  This requires
a bunch more test script code with custom send/expect.

Which direction should I go?

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

P. S.  Here is a brief explanation why the arg type is incorrect
       as written.   A pointer-to-function always has the following type:
       "returntype (*)(arglist)".  The arg type in [1] does not have a (*)
       at the top nesting level, so it is not a legal pointer-to-function.
       The arg type in [2] says: the arg is a pointer-to-function which
       returns an int and takes a single parameter which is another
       pointer-to-function that returns a long and takes a single char *
       parameter.  This arg type matches the declarations in cplusfuncs.c.