Re: [testsuite] Kfail signals.exp failures

[Andrew Cagney <cagney@gnu.org>]

> 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