[patch] KFAIL gdb/1025

[patch] KFAIL gdb/1025

[David Carlton]

I've been seeing some repeatable failures in gdb.c++/ovldbreak.exp;
this patch KFAILs them, according to PR gdb/1025 that I just filed.

Strangely enough, I'm seeing more failures than Michael does; he only
sees 4, and those only with i686-pc-linux-gnu/GCC2.95.3/DWARF-2; I'm
seeing 6 with i686-pc-linux-gnu/GCC3.{1,2}/DWARF2.  I don't know
what's weird about my setup.  (For all I know, GCC might even be doing
optimization that it shouldn't; it's not entirely clear to me from
skimming the assembly code.)

I've committed the attached patch.

David Carlton
carlton@math.stanford.edu

2003-02-03  David Carlton  <carlton@math.stanford.edu>

	* gdb.c++/ovldbreak.exp (continue_to_bp_overloaded): Add
	'might_kfail' arg.
	KFAIL some of the continue_to_bp_overloaded calls, according to
	PR c++/1025.

Index: ovldbreak.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/ovldbreak.exp,v
retrieving revision 1.4
diff -u -p -r1.4 ovldbreak.exp
--- ovldbreak.exp	18 Apr 2002 03:23:52 -0000	1.4
+++ ovldbreak.exp	4 Feb 2003 01:06:33 -0000
@@ -312,7 +312,11 @@ gdb_test "info break" \
 
 # Run through each breakpoint.
 
-proc continue_to_bp_overloaded {bpnumber argtype actuals} {
+# NOTE: carlton/2003-02-03: I'm seeing failures on some of the tests,
+# with the wrong arg being printed out.  Michael Chastain sees
+# failures at times, too, albeit fewer than I do.
+
+proc continue_to_bp_overloaded {might_kfail bpnumber argtype actuals} {
     global gdb_prompt hex decimal srcfile 
 
     send_gdb "continue\n"
@@ -320,6 +324,13 @@ proc continue_to_bp_overloaded {bpnumber
 	-re "Continuing.\r\n\r\nBreakpoint ${bpnumber}, (${hex} in )?foo::overload1arg(\\(${argtype}\\))? \\(this=${hex}(, )?${actuals}\\) at.*${srcfile}:${decimal}\r\n${decimal}\[\t \]+int foo::overload1arg \\(${argtype}( arg)?\\).*\r\n.*$gdb_prompt $" {
 	    pass "continue to bp overloaded : ${argtype}"
 	}
+	-re "Continuing.\r\n\r\nBreakpoint ${bpnumber}, (${hex} in )?foo::overload1arg(\\(${argtype}\\))? \\(this=${hex}, arg=.*\\) at.*${srcfile}:${decimal}\r\n${decimal}\[\t \]+int foo::overload1arg \\(${argtype}( arg)?\\).*\r\n.*$gdb_prompt $" {
+	    if $might_kfail {
+		kfail "gdb/1025" "continue to bp overloaded : ${argtype}"
+	    } else {
+		fail "continue to bp overloaded : ${argtype}"
+	    }
+	}
         -re ".*$gdb_prompt $" {
 	    fail "continue to bp overloaded : ${argtype}" 
 	}
@@ -329,18 +340,18 @@ proc continue_to_bp_overloaded {bpnumber
     }
 }
 
-continue_to_bp_overloaded 25 "(void|)" ""
-continue_to_bp_overloaded 24 "char" "arg=2 \\'\\\\002\\'"
-continue_to_bp_overloaded 23 "signed char" "arg=3 \\'\\\\003\\'"
-continue_to_bp_overloaded 22 "unsigned char" "arg=4 \\'\\\\004\\'"
-continue_to_bp_overloaded 21 "short" "arg=5"
-continue_to_bp_overloaded 20 "unsigned short" "arg=6"
-continue_to_bp_overloaded 19 "int" "arg=7"
-continue_to_bp_overloaded 18 "(unsigned|unsigned int)" "arg=8"
-continue_to_bp_overloaded 17 "long" "arg=9"
-continue_to_bp_overloaded 16 "unsigned long" "arg=10"
-continue_to_bp_overloaded 15 "float" "arg=100"
-continue_to_bp_overloaded 14 "double" "arg=200"
+continue_to_bp_overloaded 0 25 "(void|)" ""
+continue_to_bp_overloaded 1 24 "char" "arg=2 \\'\\\\002\\'"
+continue_to_bp_overloaded 1 23 "signed char" "arg=3 \\'\\\\003\\'"
+continue_to_bp_overloaded 1 22 "unsigned char" "arg=4 \\'\\\\004\\'"
+continue_to_bp_overloaded 1 21 "short" "arg=5"
+continue_to_bp_overloaded 1 20 "unsigned short" "arg=6"
+continue_to_bp_overloaded 0 19 "int" "arg=7"
+continue_to_bp_overloaded 0 18 "(unsigned|unsigned int)" "arg=8"
+continue_to_bp_overloaded 0 17 "long" "arg=9"
+continue_to_bp_overloaded 0 16 "unsigned long" "arg=10"
+continue_to_bp_overloaded 0 15 "float" "arg=100"
+continue_to_bp_overloaded 1 14 "double" "arg=200"
 
 
 

Re: [patch] KFAIL gdb/1025

[Daniel Jacobowitz]

On Mon, Feb 03, 2003 at 05:18:17PM -0800, David Carlton wrote:
> I've been seeing some repeatable failures in gdb.c++/ovldbreak.exp;
> this patch KFAILs them, according to PR gdb/1025 that I just filed.
> 
> Strangely enough, I'm seeing more failures than Michael does; he only
> sees 4, and those only with i686-pc-linux-gnu/GCC2.95.3/DWARF-2; I'm
> seeing 6 with i686-pc-linux-gnu/GCC3.{1,2}/DWARF2.  I don't know
> what's weird about my setup.  (For all I know, GCC might even be doing
> optimization that it shouldn't; it's not entirely clear to me from
> skimming the assembly code.)
> 
> I've committed the attached patch.

I'm really not comfortable with this use of KFAIL.  My hope was that we
would analyze particular failures before KFAILing them off to oblivion. 
I spent time fixing these exact six failures a bit under a month ago;
if it isn't working for your setup I want more information.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] KFAIL gdb/1025

[David Carlton]

On Tue, 4 Feb 2003 09:44:15 -0500, Daniel Jacobowitz <drow@mvista.com> said:

> I'm really not comfortable with this use of KFAIL.  My hope was that
> we would analyze particular failures before KFAILing them off to
> oblivion.  I spent time fixing these exact six failures a bit under
> a month ago; if it isn't working for your setup I want more
> information.

This I disagree with.  Next time, I'll wait a day before KFAILing it,
if you like.  But, from my point of view, what I have done is the
exact opposite of sending them off to oblivion: before I KFAILed them,
the bug was only visible in my test suite and in some of Michael's
test runs, whereas now it's in the much more visible location of an
open bug in the bug database.

If I uncover a new bug, that's one thing: I haven't rushed to file a
bug report+KFAIL for the overloading bug that I turned up last Friday,
because I'm happy to wait for Daniel to look at that patch.  But this
is a failure that I've seen in the test suite since I started working
on GDB and that also shows up on Michael's tables (to some extent).

If, of course, it is a bug.  To answer questions that have been raised
elsewhere:

* I'm using the binutils that comes with Red Hat 7.3; rpm -q reports
  it as binutils-2.11.93.0.2-11.  So it's old.  I'll upgrade that and
  see what happens.  (And then do what to the test?  Turn it from
  KFAIL into XFAIL, I suppose?)

* I gave the wrong GDB version: I was using CVS GDB from yesterday.  I
  saw the FAILs using 'make check' on yesterday's CVS, but then I
  investigated it using whatever GDB happened to be in /usr/local/bin
  (which, if you're curious, is the current dictionary branch GDB, and
  I haven't sync'd with mainline since whatever old date I listed).  I
  try to remember to use CVS GDB when investigating bugs, so I get the
  date entered right, but sometimes I forget.

And I have some other questions/comments:

* If it's all due to binutils, why do Michael's tables still show some
  non-PASS results with GCC 2.95.3/DWARF-2?

* It's not the same as PR 872.  That's about overload resolution; this
  bug doesn't seem to be related to overload resolution.

Anyways, I'll upgrade my binutils when I have some free time (probably
this afternoon) and see how that affects matters.

David Carlton
carlton@math.stanford.edu

Re: [patch] KFAIL gdb/1025

[Daniel Jacobowitz]

On Tue, Feb 04, 2003 at 09:16:57AM -0800, David Carlton wrote:
> * I'm using the binutils that comes with Red Hat 7.3; rpm -q reports
>   it as binutils-2.11.93.0.2-11.  So it's old.  I'll upgrade that and
>   see what happens.  (And then do what to the test?  Turn it from
>   KFAIL into XFAIL, I suppose?)

That depends on the nature of the failure.  It might still be a KFAIL.

> * I gave the wrong GDB version: I was using CVS GDB from yesterday.  I
>   saw the FAILs using 'make check' on yesterday's CVS, but then I
>   investigated it using whatever GDB happened to be in /usr/local/bin
>   (which, if you're curious, is the current dictionary branch GDB, and
>   I haven't sync'd with mainline since whatever old date I listed).  I
>   try to remember to use CVS GDB when investigating bugs, so I get the
>   date entered right, but sometimes I forget.
> 
> And I have some other questions/comments:
> 
> * If it's all due to binutils, why do Michael's tables still show some
>   non-PASS results with GCC 2.95.3/DWARF-2?
> 
> * It's not the same as PR 872.  That's about overload resolution; this
>   bug doesn't seem to be related to overload resolution.

Oh, blah, my apologies.  overload.exp has tests with almost the same
names.  If you could send me a compiled binary which does show the
problem I'd appreciate that.  Attach it to the PR maybe.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] KFAIL gdb/1025

[David Carlton]

On 04 Feb 2003 09:16:57 -0800, David Carlton <carlton@math.Stanford.EDU> said:

> Anyways, I'll upgrade my binutils when I have some free time (probably
> this afternoon) and see how that affects matters.

Okay, I've upgraded binutils to 2.13.2.1; these failures go away,
along with failures on several other tests.  (Though the down side is
that I can't compile all the programs in gdb.java now; a pity, but
I'll survive.)

But I do see the failures that Michael reports with GCC 2.95.3
combined with DWARF 2.  (In other words, failures on the tests that
are smaller than ints, though not the double failure that I had been
seeing with the old binutils.)  So I'm leaving the PR open for now; if
we ever figure out what's up with that, we can close the PR and/or
XFAIL the tests, as appropriate.

David Carlton
carlton@math.stanford.edu

Re: [patch] KFAIL gdb/1025

[David Carlton]

On 04 Feb 2003 14:28:35 -0800, David Carlton <carlton@math.Stanford.EDU> said:

> Okay, I've upgraded binutils to 2.13.2.1; these failures go away,
> along with failures on several other tests.  (Though the down side is
> that I can't compile all the programs in gdb.java now; a pity, but
> I'll survive.)

If anybody's curious, this is apparently a known bug in GCC, that has
been fixed in mainline but not, I think, in branches (including
3.2.2); see <http://gcc.gnu.org/ml/java-patches/2002-q4/msg00376.html>
for a reference.

David Carlton
carlton@math.stanford.edu

Re: [patch] KFAIL gdb/1025

[Michael Elizabeth Chastain]

drow> I'm really not comfortable with this use of KFAIL.  My hope was that we
drow> would analyze particular failures before KFAILing them off to oblivion. 
drow> I spent time fixing these exact six failures a bit under a month ago;
drow> if it isn't working for your setup I want more information.

Well, there's a tension between 'getting work done' and 'checking
with other people'.  In this particular case, waiting a few hours
would have drawn some info from me and Daniel J.  We can't win them
all.

I'm more concerned about the 'KFAILing them off to oblivion'.
I foresee that we are going to have a culture clash over KFAIL.
To me, KFAIL means that the bug is known; but to everybody else,
it's going to take on the meaning that the bug is low-priority.
These properties are orthogonal but I can see KFAIL taking on that
twisted connotation.

Michael C

Re: [patch] KFAIL gdb/1025

[Michael Elizabeth Chastain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]

Oh man, this issue is "Time Sink of the Day" for 2003-02-04.
I'm gonna drop out of the KFAIL philosophy discussion.

David C points out:

  * I gave the wrong GDB version: I was using CVS GDB from yesterday.  I
    saw the FAILs using 'make check' on yesterday's CVS, but then I
    investigated it using whatever GDB happened to be in /usr/local/bin

Before anything else, check the gdb.log file which has the broken
results and check the gdb banner when gdb starts up, so we can get
the "2002-12-23" facet off the table.

  * It's not the same as PR 872.  That's about overload resolution; this
    bug doesn't seem to be related to overload resolution.

You are right.  PR 872 is in 'overload.exp'.  This bug manifests
in 'ovldbreak.exp'.  I confuse the two a lot.  (It was bad design to
have one file name be a subset of the other.)

  * If it's all due to binutils, why do Michael's tables still show some
    non-PASS results with GCC 2.95.3/DWARF-2?

Hmmm.  I confess I am wrong that it is *all* binutils.  Now I think
there is a binutils component, but then there is a second bug on top of
that which is not analyzed yet.

Let me have a look at my FAILs:

  # target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0
  # gdb=5.3, gcc=2.95.3, binutils=2.13.2.1, libc=2.2.93-5-rh
  # gformat=dwarf-2
  Breakpoint 24, 0x080495a2 in foo::overload1arg (this=0xbffff7c4, arg=-65 '¿') at
  /berman/migchain/source/gdb-5.3/gdb/testsuite/gdb.c++/ovldbreak.cc:111^M
  111     int foo::overload1arg (char arg)            { arg = 0; return 2;}^M
  (gdb) FAIL: gdb.c++/ovldbreak.exp: continue to bp overloaded : char

The test script wants to see 'arg=2' here, but gdb prints 'arg=-65'.
That's the bug.  It's definitely not not not gdb/872.

  * I'm using the binutils that comes with Red Hat 7.3; rpm -q reports
    it as binutils-2.11.93.0.2-11.  So it's old.  I'll upgrade that and
    see what happens.  (And then do what to the test?  Turn it from
    KFAIL into XFAIL, I suppose?)

If it fails with binutils 2.13.2.1, try binutils HEAD if you have enough
patience.  Then add more info to PR gdb/1025.

I will also dig into my test results and add info PR gdb/1025.

It's really hard to tell whether a bad result is a binutils bug or
a gdb bug.  I think Daniel J would have to look at it closely at
that point, because he knows both sides of the binutils/gdb interface.

Michael C

Re: [patch] KFAIL gdb/1025

[Michael Elizabeth Chastain]

Daniel J writes:
> Oh, blah, my apologies.  overload.exp has tests with almost the same
> names.  If you could send me a compiled binary which does show the
> problem I'd appreciate that.  Attach it to the PR maybe.

I tossed up an attachment with a source file, .s file, .exe file,
and a typescript of a gdb session.

Michael C

Re: [patch] KFAIL gdb/1025

[Michael Elizabeth Chastain]

What error messages are you getting in gdb.java?

I've been getting some too.  This is a new issue.

> So I'm leaving the PR open for now; if we ever figure out what's up with
> that, we can close the PR and/or XFAIL the tests, as appropriate.

Sounds good.  I think we have this issue under control.

Michael C

Re: [patch] KFAIL gdb/1025

[Michael Elizabeth Chastain]

Weird, my notes say that gcc 3.0.4 had this problem but that
gcc 3.1 and later did not.  But I am definitely not seeing any
'description field too big' messages with my test bed,
and that includes gcc 3.2.1, gcc 3.2.2-20030203, and gcc-3_2-branch,
with binutils 2.13.2.1 and -gstabs+.

Aha.  My test bed runs with:

  runtest ... --target-board unix/gdb:debug_flags=-gstabs+

But the gcj command is not getting invoked with -gstabs+.  So I am
always testing gcj with the default debug format, which explains
my results.

Argh.  Yet another dejagnu mystery to look into.  David, how do you
run the test suite?

Michael C

Re: [patch] KFAIL gdb/1025

[David Carlton]

On Fri, 7 Feb 2003 10:16:36 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

> Argh.  Yet another dejagnu mystery to look into.  David, how do you
> run the test suite?

I normally run it via 'make check', with no tinkering with the various
files.

David Carlton
carlton@math.stanford.edu

Re: [patch] KFAIL gdb/1025

[Michael Elizabeth Chastain]

David C> I normally run it via 'make check', with no tinkering with the
David C> various files.

Then I wonder how you are getting stabs+ with gcc 3.1.

Actually, I'm a bit confused.  Are you actually seeing these specific
'description field too big' messages in your gdb.log?

Michael C

Re: [patch] KFAIL gdb/1025

[David Carlton]

On Fri, 7 Feb 2003 11:08:53 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

> David C> I normally run it via 'make check', with no tinkering with the
> David C> various files.

> Then I wonder how you are getting stabs+ with gcc 3.1.

> Actually, I'm a bit confused.  Are you actually seeing these specific
> 'description field too big' messages in your gdb.log?

Yup.  See below.  This is an invocation via runtest instead of make
check, but I'm 95% sure I get the same error message via 'make check':
certainly this test won't run under 'make check' either.

David Carlton
carlton@math.stanford.edu

jackfruit$ runtest gdb.java/jmisc.exp
WARNING: Couldn't find the global config file.
Test Run By carlton on Fri Feb  7 09:10:05 2003
Native configuration is i686-pc-linux-gnu

		=== gdb tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./gdb.java/jmisc.exp ...

		=== gdb Summary ===

# of untested testcases		1
more /extra/gdb/mirror/src/gdb/testsuite/../../gdb/gdb version  2003-02-06-cvs -nx

jackfruit$ more gdb.log 
Test Run By carlton on Fri Feb  7 09:10:05 2003
Native configuration is i686-pc-linux-gnu

		=== gdb tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./gdb.java/jmisc.exp ...
Executing on host: gcj ./gdb.java/jmisc.java  --main=jmisc -g  -o /extra/gdb/mirror/src/gdb/testsuite/gdb.java/jmisc    (timeout = 300)
spawn gcj ./gdb.java/jmisc.java --main=jmisc -g -o /extra/gdb/mirror/src/gdb/testsuite/gdb.java/jmisc 
/tmp/ccezwoW0.s: Assembler messages:
/tmp/ccezwoW0.s:28: Warning: .stabs: description field '10001' too big, try a different debug format
/tmp/ccezwoW0.s:57: Warning: .stabs: description field '60004' too big, try a different debug format
output is:
/tmp/ccezwoW0.s: Assembler messages:
/tmp/ccezwoW0.s:28: Warning: .stabs: description field '10001' too big, try a di
fferent debug format
/tmp/ccezwoW0.s:57: Warning: .stabs: description field '60004' too big, try a different debug format

UNTESTED: gdb.java/jmisc.exp: Couldn't compile ./gdb.java/jmisc.java
testcase ./gdb.java/jmisc.exp completed in 3 seconds

		=== gdb Summary ===

# of untested testcases		1
Executing on host: /extra/gdb/mirror/src/gdb/testsuite/../../gdb/gdb -nw --command gdb_cmd    (timeout = 300)
spawn /extra/gdb/mirror/src/gdb/testsuite/../../gdb/gdb -nw --command gdb_cmd 
GNU gdb 2003-02-06-cvs
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
/extra/gdb/mirror/src/gdb/testsuite/../../gdb/gdb version  2003-02-06-cvs -nx

runtest completed at Fri Feb  7 09:10:11 2003

Re: [patch] KFAIL gdb/1025

[Michael Elizabeth Chastain]

Perhaps there is a $PATH / build issue.  Check 'gcj --version' and also
check that the directory where you installed your gcc 3.1 has a
gcj binary in it.

I am guessing that you built your gcc 3.1 without gcj and that you are
picking up the base gcj on your system.  Or maybe you have some
uberbaum-ish tree and runtest is messing with $PATH as well.

  spawn gcj ./gdb.java/jmisc.java --main=jmisc -g -o /extra/gdb/mirror/src/gdb/testsuite/gdb.java/jmisc 
  /tmp/ccezwoW0.s: Assembler messages:
  /tmp/ccezwoW0.s:28: Warning: .stabs: description field '10001' too big, try a different debug format
  /tmp/ccezwoW0.s:57: Warning: .stabs: description field '60004' too big, try a different debug format

There's definitely no '-gstabs+' there, and definitely '.stabs' warning
messages.  Strange.

Michael C

Re: [patch] KFAIL gdb/1025

[David Carlton]

On Fri, 7 Feb 2003 11:40:13 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

> I am guessing that you built your gcc 3.1 without gcj and that you are
> picking up the base gcj on your system.

Bingo.  Good call.

David Carlton
carlton@math.stanford.edu