Re: [rfa] Gut signals.exp

[Daniel Jacobowitz <drow@false.org>]

On Tue, Sep 07, 2004 at 10:11:42AM -0400, Andrew Cagney wrote:
> The only interesting bit [well I think] is that I'm also removing 
> several xfails.  The xfailed test (it should have been a kfail) is 
> checking that GDB remembers that it was single-stepping, so that when a 
> signal handler breakpoint is hit and then continued, GDB resumes the 
> earlier single-step task.  Making this work would involve a stack of 
> outstanding commands and would require a very good UI design. 
> Consequently, I think the feature & test can be dropped until someone is 
> motivated to design / implement it.

I'd like to have a record of this, since I've wanted it several times.
Would you please file a PR, if there isn't one already?  Beyond that I
don't care if it's tested.  Tests for unimplemented features don't do
much good.

> -	# 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"

Ignoring that I obviously got the analysis and the kfails wrong, did
the Linux kernel patch you mentioned fix this test in the previous
version of signals.exp?  If not, is there another failing test that you
are confident is the same problem?

I'm guessing the former but I can't check myself.

-- 
Daniel Jacobowitz