[testsuite] Kfail signals.exp failures

[testsuite] Kfail signals.exp failures

[Daniel Jacobowitz]

Andrew removed some "suspicious" xfails in signals.exp when he
overhauled it.  They're a legitimate bug in GDB; I've put a complete
analysis in PR 1738.  I expect all hardware single step targets to
fail; I maintained the previous list from the removed setup_xfails
(and added x86_64).

OK?

-- 
Daniel Jacobowitz

2004-08-08  Daniel Jacobowitz  <dan@debian.org>

	PR gdb/1738
	* gdb.base/signals.exp (signal_tests_1): KFAIL bug in continuing
	from a breakpoint with a pending signal.

Index: testsuite/gdb.base/signals.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/signals.exp,v
retrieving revision 1.8
diff -u -p -r1.8 signals.exp
--- testsuite/gdb.base/signals.exp	20 Jul 2004 19:59:26 -0000	1.8
+++ testsuite/gdb.base/signals.exp	8 Aug 2004 23:16:17 -0000
@@ -114,9 +114,24 @@ proc signal_tests_1 {} {
 	# In running to func2, the 2rd alarm call will have been set
 	# up, let it be delivered.
 
+	# This doesn't work correctly on platforms with hardware single
+	# step...
+
 	sleep 2
+
+	setup_kfail "i*86-*-*" gdb/1738
+	setup_kfail "x86_64-*-*" gdb/1738
+	setup_kfail "rs6000-*-*" gdb/1738
+	setup_kfail "powerpc-*-*" gdb/1738
+	setup_kfail "sparc-*-*" gdb/1738
 	gdb_test "continue" "Breakpoint.*handler.*" \
 	    "continue to handler for 3rd alarm call"
+
+	setup_kfail "i*86-*-*" gdb/1738
+	setup_kfail "x86_64-*-*" gdb/1738
+	setup_kfail "rs6000-*-*" gdb/1738
+	setup_kfail "powerpc-*-*" gdb/1738
+	setup_kfail "sparc-*-*" gdb/1738
 	gdb_test "backtrace" \
 	    "#0  handler.*#1.*signal handler called.*#2  func2.*#3.*main.*" \
 	    "backtrace for 3rd alarm"

Re: [testsuite] Kfail signals.exp failures

[Michael Chastain]

Daniel Jacobowitz <drow@false.org> wrote:
> Andrew removed some "suspicious" xfails in signals.exp when he
> overhauled it.  They're a legitimate bug in GDB; I've put a complete
> analysis in PR 1738.  I expect all hardware single step targets to
> fail; I maintained the previous list from the removed setup_xfails
> (and added x86_64).

Neat.  This patch is approved.

Michael C

> 2004-08-08  Daniel Jacobowitz  <dan@debian.org>
>
> 	PR gdb/1738
> 	* gdb.base/signals.exp (signal_tests_1): KFAIL bug in continuing
> 	from a breakpoint with a pending signal.

Re: [testsuite] Kfail signals.exp failures

[Mark Kettenis]

   Date: Sun, 8 Aug 2004 19:18:10 -0400
   From: Daniel Jacobowitz <drow@false.org>

   2004-08-08  Daniel Jacobowitz  <dan@debian.org>

	   PR gdb/1738
	   * gdb.base/signals.exp (signal_tests_1): KFAIL bug in continuing
	   from a breakpoint with a pending signal.

Hmm, SPARC doesn't have hardware single-step.  Solaris SPARC has
single-stepping implemented in the kernel, but all other OS'es don't
have that.

Mark

Re: [testsuite] Kfail signals.exp failures

[Daniel Jacobowitz]

On Mon, Aug 09, 2004 at 09:45:49AM +0200, Mark Kettenis wrote:
>    Date: Sun, 8 Aug 2004 19:18:10 -0400
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    2004-08-08  Daniel Jacobowitz  <dan@debian.org>
> 
> 	   PR gdb/1738
> 	   * gdb.base/signals.exp (signal_tests_1): KFAIL bug in continuing
> 	   from a breakpoint with a pending signal.
> 
> Hmm, SPARC doesn't have hardware single-step.  Solaris SPARC has
> single-stepping implemented in the kernel, but all other OS'es don't
> have that.

I wonder if this test passes anywhere?  Thinking about it again, the
software singlestep breakpoint is inserted when !breakpoints_inserted,
so the same problem should apply.

-- 
Daniel Jacobowitz

Re: [testsuite] Kfail signals.exp failures

[Daniel Jacobowitz]

On Mon, Aug 09, 2004 at 03:00:30AM -0400, Michael Chastain wrote:
> Daniel Jacobowitz <drow@false.org> wrote:
> > Andrew removed some "suspicious" xfails in signals.exp when he
> > overhauled it.  They're a legitimate bug in GDB; I've put a complete
> > analysis in PR 1738.  I expect all hardware single step targets to
> > fail; I maintained the previous list from the removed setup_xfails
> > (and added x86_64).
> 
> Neat.  This patch is approved.

Checked in.  We may need to refine the target list later...

This covers most of the FAILs on my i686-pc-linux-gnu system.  The
remaining are corefile.exp (blocked on vsyscall support);
null_record.exp (something has broken in GDB's debug info, maybe?);
and watchthread.exp (there's a bug in the test script, but I can't test
the patch, because it also triggers some internal bugs in GDB).

-- 
Daniel Jacobowitz

Re: [testsuite] Kfail signals.exp failures

[Andrew Cagney]

> On Mon, Aug 09, 2004 at 09:45:49AM +0200, Mark Kettenis wrote:
> 
>>>    Date: Sun, 8 Aug 2004 19:18:10 -0400
>>>    From: Daniel Jacobowitz <drow@false.org>
>>> 
>>>    2004-08-08  Daniel Jacobowitz  <dan@debian.org>
>>> 
>>> 	   PR gdb/1738
>>> 	   * gdb.base/signals.exp (signal_tests_1): KFAIL bug in continuing
>>> 	   from a breakpoint with a pending signal.
>>> 
>>> Hmm, SPARC doesn't have hardware single-step.  Solaris SPARC has
>>> single-stepping implemented in the kernel, but all other OS'es don't
>>> have that.
> 
> 
> I wonder if this test passes anywhere?  Thinking about it again, the
> software singlestep breakpoint is inserted when !breakpoints_inserted,
> so the same problem should apply.

Yep.  The existing test passes on s390 GNU/Linux:
http://sources.redhat.com/ml/gdb-testers/2004-q3/msg00068.html
and my local PPC NetBSD machine.  Both have h/w single-step.  See 
breakpoints/1702.

You appear to have found a new bug.  Given all the potential 
combinations of step / next / continue VS breakpoint at/in handler VS 
handle its self, we may want to split this out of signals.exp and into a 
new expanded test file.  Either way, a new test is needed.

BTW, does sigbpt.exp pass?  It's testing a related stepi edge case.

Michael, those KFAILs are not correct.

Andrew

Re: [testsuite] Kfail signals.exp failures

[Daniel Jacobowitz]

On Mon, Aug 09, 2004 at 09:58:46AM -0400, Andrew Cagney wrote:
> >On Mon, Aug 09, 2004 at 09:45:49AM +0200, Mark Kettenis wrote:
> >
> >>>   Date: Sun, 8 Aug 2004 19:18:10 -0400
> >>>   From: Daniel Jacobowitz <drow@false.org>
> >>>
> >>>   2004-08-08  Daniel Jacobowitz  <dan@debian.org>
> >>>
> >>>	   PR gdb/1738
> >>>	   * gdb.base/signals.exp (signal_tests_1): KFAIL bug in continuing
> >>>	   from a breakpoint with a pending signal.
> >>>
> >>>Hmm, SPARC doesn't have hardware single-step.  Solaris SPARC has
> >>>single-stepping implemented in the kernel, but all other OS'es don't
> >>>have that.
> >
> >
> >I wonder if this test passes anywhere?  Thinking about it again, the
> >software singlestep breakpoint is inserted when !breakpoints_inserted,
> >so the same problem should apply.
> 
> Yep.  The existing test passes on s390 GNU/Linux:
> http://sources.redhat.com/ml/gdb-testers/2004-q3/msg00068.html
> and my local PPC NetBSD machine.  Both have h/w single-step.  See 
> breakpoints/1702.
> 
> You appear to have found a new bug.  Given all the potential 
> combinations of step / next / continue VS breakpoint at/in handler VS 
> handle its self, we may want to split this out of signals.exp and into a 
> new expanded test file.  Either way, a new test is needed.
> 
> BTW, does sigbpt.exp pass?  It's testing a related stepi edge case.
> 
> Michael, those KFAILs are not correct.

Yes, sigbpt.exp passes.

breakpoints/1702 is about the tendency of ia32 hardware to step two
instructions over int $0x80.  That does not affect this test case; see
the analysis in gdb/1738.

Please explain why the KFAILs are not correct, or why a new test is
needed.  This is a bug in GDB; I analyzed the bug, filed a bug report,
and marked the test which fails because of this bug as KFAILed to the
PR.  Judging from the historical use of XFAIL, this is the precise bug
that the test was written for.

My analysis does not explain why it passes on S/390, or on PPC.  If you
want to, then remove the PPC kfail.

-- 
Daniel Jacobowitz

Re: [testsuite] Kfail signals.exp failures

[Andrew Cagney]

> Yes, sigbpt.exp passes.
> 
> breakpoints/1702 is about the tendency of ia32 hardware to step two
> instructions over int $0x80.  That does not affect this test case; see
> the analysis in gdb/1738.

1702 is about broken kernels.  Both the s390 and PPC in question have a 
fixed kernel.  Since sigbpt.exp passes it soulds like your kernel is fixed?

> Please explain why the KFAILs are not correct, or why a new test is
> needed.  This is a bug in GDB; I analyzed the bug, filed a bug report,
> and marked the test which fails because of this bug as KFAILed to the
> PR.  Judging from the historical use of XFAIL, this is the precise bug
> that the test was written for.

Here's the original comment that went with the XFAILs:

# GDB yanks out the breakpoints to step over the breakpoint it
# stopped at, which means the breakpoint at handler is yanked.
# But if SOFTWARE_SINGLE_STEP_P, we won't get another chance to
# reinsert them (at least not with procfs, where we tell the kernel
# not to tell gdb about `pass' signals).  So the fix would appear to
# be to just yank that one breakpoint when we step over it.

and here's the new comment:

# This doesn't work correctly on platforms with hardware single
# step...

The test does pass on systems with working h/w single-step.  Can we fix 
the comment?

> My analysis does not explain why it passes on S/390, or on PPC.  If you
> want to, then remove the PPC kfail.

More anaysis and tests are needed here:

- something to cover "next" (next is different to continue)
- something to explain why i386 (what other systems did you test this 
on?) fails the continue (decr pc after break?)

can we do that?

Andrew

Re: [testsuite] Kfail signals.exp failures

[Michael Chastain]

Andrew Cagney <cagney@gnu.org> wrote:
> You appear to have found a new bug.  Given all the potential 
> combinations of step / next / continue VS breakpoint at/in handler VS 
> handle its self, we may want to split this out of signals.exp and into a 
> new expanded test file.  Either way, a new test is needed.
>
> BTW, does sigbpt.exp pass?  It's testing a related stepi edge case.
>
> Michael, those KFAILs are not correct.

Mmmm, I seem to have put my foot in it.  I will admit that I am beyond
my depth in dealing with the signals tests.

Perhaps we should move all the signals tests to a new subdirectory
gdb.signal, and delegate someone else to be senior maintainer for
that subdirectory?  I would feel competent to be junior maintainer.

If we don't do that, then I'm going to try something new in gdb
maintainership: delegation.  I'll ask for 2 or 3 expert volunteers,
and I'll approve a signals patch just when there's unanimous consent
among the experts.

And I've made a note to read up on signals tests.

Michael C

Re: [testsuite] Kfail signals.exp failures

[Andreas Schwab]

Andrew Cagney <cagney@gnu.org> writes:

>> On Mon, Aug 09, 2004 at 09:45:49AM +0200, Mark Kettenis wrote:
>> 
>>>>    Date: Sun, 8 Aug 2004 19:18:10 -0400
>>>>    From: Daniel Jacobowitz <drow@false.org>
>>>>    2004-08-08  Daniel Jacobowitz  <dan@debian.org>
>>>> 	   PR gdb/1738
>>>> 	   * gdb.base/signals.exp (signal_tests_1): KFAIL bug in continuing
>>>> 	   from a breakpoint with a pending signal.
>>>> Hmm, SPARC doesn't have hardware single-step.  Solaris SPARC has
>>>> single-stepping implemented in the kernel, but all other OS'es don't
>>>> have that.
>> I wonder if this test passes anywhere?  Thinking about it again, the
>> software singlestep breakpoint is inserted when !breakpoints_inserted,
>> so the same problem should apply.
>
> Yep.  The existing test passes on s390 GNU/Linux:
> http://sources.redhat.com/ml/gdb-testers/2004-q3/msg00068.html
> and my local PPC NetBSD machine.  Both have h/w single-step.

FWIW, it also passes on m68k-linux.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [testsuite] Kfail signals.exp failures

[Andrew Cagney]

> Perhaps we should move all the signals tests to a new subdirectory
> gdb.signal, and delegate someone else to be senior maintainer for
> that subdirectory?  I would feel competent to be junior maintainer.

Well, you're actually doing your job to a tee.  You made a decision 
based on the best available information, and then when more information 
came to light, revised the decision, and learn't from the experience :-)

(I've now posted fixes to both signals.exp and sigstep.exp)

As for a separate signals directory, this code is really testing 
infrun.c (ya), and makes for some fundamental functionality (should have 
been fixed working 10+ years ago), so I think still belongs in gdb.base. 
  Besides I've been naming all the files sig*.exp so that they are easy 
to identify.

I think its better to reserve new directories for things that are 
clearly separate -> stabs edge cases, dwarf edge cases, C++ lang stuff, 
...  We could too easily end up with a pedantic debate over which 
directory a test belongs (...) :-)

> If we don't do that, then I'm going to try something new in gdb
> maintainership: delegation.  I'll ask for 2 or 3 expert volunteers,
> and I'll approve a signals patch just when there's unanimous consent
> among the experts.
> 
> And I've made a note to read up on signals tests.

Andrew

Re: [testsuite] Kfail signals.exp failures

[Mark Kettenis]

   Date: Tue, 24 Aug 2004 18:33:47 -0400
   From: Andrew Cagney <cagney@gnu.org>

   As for a separate signals directory, this code is really testing 
   infrun.c (ya), and makes for some fundamental functionality (should have 
   been fixed working 10+ years ago), so I think still belongs in gdb.base. 
     Besides I've been naming all the files sig*.exp so that they are easy 
   to identify.

   I think its better to reserve new directories for things that are 
   clearly separate -> stabs edge cases, dwarf edge cases, C++ lang stuff, 
   ...  We could too easily end up with a pedantic debate over which 
   directory a test belongs (...) :-)

I agree with Andrew here.