2004-07-20 Andrew Cagney <cagney@gnu.org>

	* gdb.base/signals.exp: Replace send_gdb and gdb_expect with
	gdb_test and gdb_test_multiple.  Delete bash_bug.  Delete suspect
	XFAILs.  Clean up test messages and comments.  Check backtraces.
	Delete re-sync code.

2 files changed, 144 insertions, 440 deletions

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 84d1b51..34fb35a 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,10 @@
+2004-07-20  Andrew Cagney  <cagney@gnu.org>
+
+	* gdb.base/signals.exp: Replace send_gdb and gdb_expect with
+	gdb_test and gdb_test_multiple.  Delete bash_bug.  Delete suspect
+	XFAILs.  Clean up test messages and comments.  Check backtraces.
+	Delete re-sync code.
+
 2004-07-19  Michael Chastain  <mec.gnu@mindspring.com>
 
 	Fix PR cli/740.
diff --git a/gdb/testsuite/gdb.base/signals.exp b/gdb/testsuite/gdb.base/signals.exp
index 0ffb0c20..803ee78 100644
--- a/gdb/testsuite/gdb.base/signals.exp
+++ b/gdb/testsuite/gdb.base/signals.exp
@@ -49,130 +49,45 @@ proc signal_tests_1 {} {
     global gdb_prompt
     if [runto_main] then {
 	gdb_test "next" "signal \\(SIGUSR1.*" \
-	    "next over signal (SIGALRM, handler)"
+	    "next over signal call; SIGALRM handler"
 	gdb_test "next" "alarm \\(.*" \
-	    "next over signal (SIGUSR1, handler)"
+	    "next over signal call; SIGUSR1 handler"
+
+	# Set up an alarm, wait for it to be come pending then do a
+	# next to see what happens.
+
 	gdb_test "next" "\\+\\+count; /\\* first \\*/" \
-	    "next over alarm (1)"
-	# An alarm has been signaled, give the signal time to get delivered.
+	    "next over 1st alarm"
 	sleep 2
+	gdb_test "next" "alarm .*" \
+	    "next over first count and SIGALRM to 2nd alarm"
 
-	# NOTE: cagney/2004-05-09: The following is retained as an
-	# historical reference.  Because signal delivery when doing a
-	# next has been changed to use a continue, and not a
-	# single-step, the kernel bug of a stuck trace-bit in the
-	# trampoline's saved PS register is avoided.
-
-	# This can happen on machines that have a trace flag in their
-	# PS register.  The trace flag in the PS register will be set
-	# due to the `next' command.  Before calling the signal
-	# handler, the PS register is pushed along with the context on
-	# the user stack.  When the signal handler has finished, it
-	# reenters the the kernel via a sigreturn syscall, which
-	# restores the PS register along with the context.  If the
-	# kernel erroneously does not clear the trace flag in the
-	# pushed context, gdb will receive a SIGTRAP from the set
-	# trace flag in the restored context after the signal handler
-	# has finished.
-
-	# I do not yet understand why the SIGTRAP does not occur after
-	# stepping the instruction at the restored PC on i386 BSDI 1.0
-	# systems.
-
-	# Note that the vax under Ultrix also exhibits this behaviour
-	# (it is uncovered by the `continue from a break in a signal
-	# handler' test below).  With this test the failure is
-	# shadowed by hitting the through_sigtramp_breakpoint upon
-	# return from the signal handler.
-	
-	# SVR4 and Linux based i*86 systems exhibit this behaviour as
-	# well (it is uncovered by the `continue from a break in a
-	# signal handler' test below).  As these systems use procfs,
-	# where we tell the kernel not to tell gdb about `pass'
-	# signals, and the trace flag is cleared by the kernel before
-	# entering the sigtramp routine, GDB will not notice the
-	# execution of the signal handler.  Upon return from the
-	# signal handler, GDB will receive a SIGTRAP from the set
-	# trace flag in the restored context.  The SIGTRAP marks the
-	# end of a (albeit long winded) single step for GDB, causing
-	# this test to pass.
-
-	gdb_test "next" "alarm .*" "next to 2nd alarm"
+	# Now do the same thing but with a breakpoint in the SIGALRM
+	# handler so that we stop there.
 
 	gdb_test "break handler" "Breakpoint \[0-9\]+ .*"
 	gdb_test "next" "\\+\\+count; /\\* second \\*/" \
-	    "next to 2nd ++count in signals_tests_1"
-
-	# An alarm has been signaled, give the signal time to get
-	# delivered.
-
+	    "next over 2nd alarm"
 	sleep 2
+	gdb_test "next" "Breakpoint.*handler.*" \
+	    "next over second count, but jump to handler"
+	gdb_test "backtrace" \
+	    "#0.*handler.*#1.*signal handler.*#2.* main .*" \
+	    "backtrace for 2nd alarm"
 
-	set bash_bug 0
-	send_gdb "next\n"
-	gdb_expect {
-	    -re "Breakpoint.*handler.*$gdb_prompt $" {
-		pass "next to handler in signals_tests_1"
-	    }
-	    -re "Program received signal SIGEMT.*$gdb_prompt $" {
-		# Bash versions before 1.13.5 cause this behaviour by
-		# blocking SIGTRAP.
-		fail "next to handler in signals_tests_1 (known problem with bash versions before 1.13.5)"
-		set bash_bug 1
-		gdb_test "signal 0" "Breakpoint.*handler.*"
-	    }
-	    -re ".*$gdb_prompt $" {
-		fail "next to handler in signals_tests_1"
-	    }
-	    timeout {
-		fail "next to handler in signals_tests_1 (timeout)"
-	    }
-	    eof {
-		fail "next to handler in signals_tests_1 (eof)"
-	    }
-	}
-
-	# This doesn't test that main is frame #2, just that main is
-	# frame #2, #3, or higher.  At some point this should be fixed
-	# (but it quite possibly would introduce new FAILs on some
-	# systems).
-
-	setup_xfail "i*86-*-bsdi2.0"
-	gdb_test "backtrace 10" "#0.*handler.*#1.*signal handler.*#2.* main .*" \
-	    "backtrace in signals_tests_1"
+	# Let the signal handler return allowing main to advance to
+	# func1.
 
 	gdb_test "break func1" "Breakpoint \[0-9\]+ .*"
 	gdb_test "break func2" "Breakpoint \[0-9\]+ .*"
-
-	# NOTE: cagney/2004-05-09: Ref "next to 2nd alarm" above.
-	# Because signal delivery when doing a next has been changed
-	# to use a continue, and not a single-step, the kernel bug of
-	# a stuck trace-bit in the trampoline's saved PS register is
-	# avoided.
-
 	gdb_test "continue" "Breakpoint.*func1.*" "continue to func1"
 
-	setup_xfail "*-*-irix*"
-	send_gdb "signal SIGUSR1\n"
-	gdb_expect {
-	    -re "Breakpoint.*handler.*$gdb_prompt $" {
-		pass "signal SIGUSR1"
-	    }
-	    -re "Program received signal SIGUSR1.*$gdb_prompt $" {
-		# This is what irix4 and irix5 do.
-		# It would appear to be a kernel bug.
-		fail "signal SIGUSR1"
-		gdb_test "continue" "Breakpoint.*handler.*" "pass it SIGUSR1"
-	    }
-	    -re ".*$gdb_prompt $" {
-		fail "signal SIGUSR1"
-	    }
-	    default {
-		fail "signal SIGUSR1"
-	    }
-	}
+	# While still in func1, force a signal, check the backtrace.
 
-	# Will tend to wrongly require an extra continue.
+	gdb_test "signal SIGUSR1" "Breakpoint.*handler.*"
+	gdb_test "bt" \
+	    "#0  handler .*#1  .signal handler called.*#2  func1 .*\#3 .*main.*" \
+	    "backtrace for SIGUSR1"
 
 	# The problem here is that the breakpoint at func1 will be
 	# inserted, and when the system finishes with the signal
@@ -184,95 +99,47 @@ proc signal_tests_1 {} {
 	# anytime soon.
 
 	setup_xfail "*-*-*"
-	send_gdb "continue\n"
-	gdb_expect {
+	set test "continue to func2"
+	gdb_test_multiple "continue" "$test" {
 	    -re "Breakpoint.*func2.*$gdb_prompt $" {
-		pass "continue to func2"
+		pass "$test"
 	    }
 	    -re "Breakpoint.*func1.*$gdb_prompt $" {
-	    	fail "continue to func2"
+	    	fail "$test"
 		gdb_test "continue" "Breakpoint.*func2.*" \
 		    "extra continue to func2"
 	    }
-	    -re ".*$gdb_prompt $" {
-		fail "continue to func2"
-	    }
-	    default {
-		fail "continue to func2"
-	    }
 	}
 
-	sleep 2
+	# In running to func2, the 2rd alarm call will have been set
+	# up, let it be delivered.
 
-        # 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.
-
-	setup_xfail "sparc*-*-*"
-	setup_xfail "rs6000-*-*"
-	setup_xfail "powerpc-*-*"
-
-	# A faulty bash will not step the inferior into sigtramp on sun3.
-	if {$bash_bug} then {
-	    setup_xfail "m68*-*-sunos4*"
-	}
-	
-	setup_xfail "i*86-pc-linux-gnu*"
-	setup_xfail "i*86-*-solaris2*"
-	gdb_test "continue" "Breakpoint.*handler.*" "continue to handler"
+	sleep 2
+	gdb_test "continue" "Breakpoint.*handler.*" \
+	    "continue to handler for 3rd alarm call"
+	gdb_test "backtrace" \
+	    "#0  handler.*#1.*signal handler called.*#2  func2.*#3.*main.*" \
+	    "backtrace for 3rd alarm"
 
-	# If the SOFTWARE_SINGLE_STEP_P failure happened, we have
-	# already exited.  If we succeeded a continue will return from
-	# the handler to func2.  GDB now has `forgotten' that it
-	# intended to step over the breakpoint at func2 and will stop
-	# at func2.
+	# If we succeeded a continue will return from the handler to
+	# func2.  GDB now has `forgotten' that it intended to step
+	# over the breakpoint at func2 and will stop at func2.
 
 	setup_xfail "*-*-*"
-
-	# The sun3 with a faulty bash will also be `forgetful' but it
-	# already got the spurious stop at func2 and this continue
-	# will work.
-
-	if {$bash_bug} then {
-	     clear_xfail "m68*-*-sunos4*"
+	set test "continue to program exit"
+	gdb_test_multiple "continue" "$test" {
+	    -re "Program exited with code 010\\." {
+		pass "$test"
+	    }
+	    -re "Breakpoint.*func2.*$gdb_prompt $" {
+	    	fail "$test"
+		gdb_test "continue" "Program exited with code 010\\." \
+		    "extra continue to program exit"
+	    }
 	}
-	gdb_test "continue" "Program exited with code 010\\." \
-	    "continue to exit in signals_tests_1 "
     }
 }
 
-# On a few losing systems, ptrace (PT_CONTINUE) or ptrace (PT_STEP)
-# causes pending signals to be cleared, which causes these tests to
-# get nowhere fast.  This is totally losing behavior (perhaps there
-# are cases in which is it useful but the user needs more control,
-# which they mostly have in GDB), but some people apparently think it
-# is a feature.  It is documented in the ptrace manpage on Motorola
-# Delta Series sysV68 R3V7.1 and on HPUX 9.0.  Even the non-HPUX PA
-# OSes (BSD and OSF/1) seem to have figured they had to copy this
-# braindamage.
-
-if {[ istarget "m68*-motorola-*" ] || [ istarget "hppa*-*-bsd*" ] ||
-    [ istarget "hppa*-*-osf*" ]} then {
-    setup_xfail "*-*-*"
-    fail "ptrace loses on signals on this target"
-    return 0
-}
-
-# lynx2.2.2 doesn't lose signals, instead it screws up the stack
-# pointer in some of these tests leading to massive problems.  I've
-# reported this to lynx, hopefully it'll be fixed in lynx2.3.  Severe
-# braindamage.
-
-if [ istarget "*-*-*lynx*" ] then {
-    setup_xfail "*-*-*"
-    fail "kernel scroggs stack pointer in signal tests on this target"
-    return 0
-}
-
 gdb_exit
 gdb_start
 
@@ -305,223 +172,125 @@ gdb_reinitialize_dir $srcdir/$subdir
 gdb_load $binfile
 signal_tests_1
 
-# Force a resync, so we're looking at the right prompt.  On SCO we
-# were getting out of sync (I don't understand why).
-
-send_gdb "p 1+1\n"
-gdb_expect {
-    -re "= 2.*$gdb_prompt $" {
-    }
-    -re ".*$gdb_prompt $" {
-	perror "sync trouble in signals.exp"
-    }
-    default {
-	perror "sync trouble in signals.exp"
-    }
-}
-
 if [runto_main] then {
 
     # Since count is a static variable outside main, runto_main is no
     # guarantee that count will be 0 at this point.
 
     gdb_test "set variable count = 0" ""
+
+    # Test an inferior function call that takes a signal that hits a
+    # breakpoint (with a false condition).  When GDB tries to run the
+    # stack dummy, it will hit the breakpoint at handler.  Provided it
+    # doesn't lose its cool, this is not a problem, it just has to
+    # note that the breakpoint condition is false and keep going.
+
+    # ...setup an always false conditional breakpoint
+
     gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*"
     gdb_test "set \$handler_breakpoint_number = \$bpnum" ""
 
-    # Get to the point where a signal is waiting to be delivered
+    # ...setup the signal
 
-    gdb_test "next" "signal \\(SIGUSR1.*" "next to signal in signals.exp"
-    gdb_test "next" "alarm \\(.*" "next to alarm #1 in signals.exp"
+    gdb_test "next" "signal \\(SIGUSR1.*" "next to signal"
+    gdb_test "next" "alarm \\(.*" "next to alarm #1"
     gdb_test "next" "\\+\\+count; /\\* first \\*/" \
-	"next to ++count #1 in signals.exp"
-
-    # Give the signal time to get delivered
-
+	"next to ++count #1"
     sleep 2
-    
-    # Now call a function.  When GDB tries to run the stack dummy, it
-    # will hit the breakpoint at handler.  Provided it doesn't lose
-    # its cool, this is not a problem, it just has to note that the
-    # breakpoint condition is false and keep going.
+
+    # ...call the function
 
     gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = $void" \
-	"p func1 () #1 in signals.exp"
+	"p func1 () #1"
 
-    # Make sure the count got incremented.
+    # ...veryfiy that the cout was updated
 
-    # Haven't investigated this xfail
+    gdb_test "p count" "= 2" "p count #1"
 
-    setup_xfail "rs6000-*-*"
-    setup_xfail "powerpc-*-*"
-    gdb_test "p count" "= 2" "p count #1 in signals.exp"
-    if { [istarget "rs6000-*-*"] || [istarget "powerpc-*-*"] } {
-	return 0
-    }
+    # Now run the same test but with a breakpoint that does stop.
+
+    # ...set up the breakpoint and signal
 
     gdb_test "condition \$handler_breakpoint_number" "now unconditional\\."
-    gdb_test "next" "alarm \\(.*" "next to alarm #2 in signals.exp"
+    gdb_test "next" "alarm \\(.*" "next to alarm #2"
     gdb_test "next" "\\+\\+count; /\\* second \\*/" \
-	"next to ++count #2 in signals.exp"
+	"next to ++count #2"
     sleep 2
 
-    # This time we stop when GDB tries to run the stack dummy.  So it
-    # is OK that we do not print the return value from the function.
+    # ...call the function, which is immediatly interrupted
 
     gdb_test "p func1 ()" \
 "Breakpoint \[0-9\]*, handler.*
 The program being debugged stopped while in a function called from GDB.*" \
-	"p func1 () #2 in signals.exp"
+	"p func1 () #2"
 
-    # But we should be able to backtrace...  On alpha-*-osf2.0 this
-    # test works when run manually but sometime fails when run under
-    # dejagnu, making it very hard to debug the problem.  Weird...
+    # ...verify the backtrace
 
-    gdb_test "bt 10" "#0.*handler.*#1.*signal handler.*#2.* main .*" "bt in signals.exp"
+    gdb_test "backtrace" \
+	"#0  handler.*#1  .signal handler called.*#2  func1.*#3  .function called from gdb.*#4.*main.*" \
+	"backtrace from handler when calling func1"
 
-    # ...and continue...
+    # ...and continue (silently returning)
 
-    gdb_test "continue" "Continuing\\." "continue in signals.exp"
+    gdb_test "continue" "Continuing\\."
 
     # ...and then count should have been incremented
 
-    gdb_test "p count" "= 5" "p count #2 in signals.exp"
+    gdb_test "p count" "= 5" "p count #2"
 
 
     # Verify that "info signals" produces reasonable output.
 
-    send_gdb "info signals\n"
-    gdb_expect {
-	-re "SIGHUP.*SIGINT.*SIGQUIT.*SIGILL.*SIGTRAP.*SIGABRT.*SIGEMT.*SIGFPE.*SIGKILL.*SIGBUS.*SIGSEGV.*SIGSYS.*SIGPIPE.*SIGALRM.*SIGTERM.*SIGURG.*SIGSTOP.*SIGTSTP.*SIGCONT.*SIGCHLD.*SIGTTIN.*SIGTTOU.*SIGIO.*SIGXCPU.*SIGXFSZ.*SIGVTALRM.*SIGPROF.*SIGWINCH.*SIGLOST.*SIGUSR1.*SIGUSR2.*SIGPWR.*SIGPOLL.*SIGWIND.*SIGPHONE.*SIGWAITING.*SIGLWP.*SIGDANGER.*SIGGRANT.*SIGRETRACT.*SIGMSG.*SIGSOUND.*SIGSAK.*SIGPRIO.*SIG33.*SIG34.*SIG35.*SIG36.*SIG37.*SIG38.*SIG39.*SIG40.*SIG41.*SIG42.*SIG43.*SIG44.*SIG45.*SIG46.*SIG47.*SIG48.*SIG49.*SIG50.*SIG51.*SIG52.*SIG53.*SIG54.*SIG55.*SIG56.*SIG57.*SIG58.*SIG59.*SIG60.*SIG61.*SIG62.*SIG63.*Use the \"handle\" command to change these tables.*$gdb_prompt $" {
-	    pass "info signals"
-	}
-	-re "$gdb_prompt $" {
-	    fail "info signals"
-	}
-	timeout {
-	    fail "(timeout) info signals"
-	}
-    }
+    gdb_test "info signals" "SIGHUP.*SIGINT.*SIGQUIT.*SIGILL.*SIGTRAP.*SIGABRT.*SIGEMT.*SIGFPE.*SIGKILL.*SIGBUS.*SIGSEGV.*SIGSYS.*SIGPIPE.*SIGALRM.*SIGTERM.*SIGURG.*SIGSTOP.*SIGTSTP.*SIGCONT.*SIGCHLD.*SIGTTIN.*SIGTTOU.*SIGIO.*SIGXCPU.*SIGXFSZ.*SIGVTALRM.*SIGPROF.*SIGWINCH.*SIGLOST.*SIGUSR1.*SIGUSR2.*SIGPWR.*SIGPOLL.*SIGWIND.*SIGPHONE.*SIGWAITING.*SIGLWP.*SIGDANGER.*SIGGRANT.*SIGRETRACT.*SIGMSG.*SIGSOUND.*SIGSAK.*SIGPRIO.*SIG33.*SIG34.*SIG35.*SIG36.*SIG37.*SIG38.*SIG39.*SIG40.*SIG41.*SIG42.*SIG43.*SIG44.*SIG45.*SIG46.*SIG47.*SIG48.*SIG49.*SIG50.*SIG51.*SIG52.*SIG53.*SIG54.*SIG55.*SIG56.*SIG57.*SIG58.*SIG59.*SIG60.*SIG61.*SIG62.*SIG63.*Use the \"handle\" command to change these tables.*" \
+	"info signals"
 
     # Verify that "info signal" correctly handles an argument, be it a
     # symbolic signal name, or an integer ID.
 
-    send_gdb "info signal SIGTRAP\n"
-    gdb_expect {
-	-re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $" {
-	    pass "info signal SIGTRAP"
-	}
-	-re "$gdb_prompt $" {
-	    fail "info signal SIGTRAP"
-	}
-	timeout {
-	    fail "(timeout) info signal SIGTRAP"
-	}
-    }
+    gdb_test "info signal SIGTRAP" \
+	"SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*" \
+	"info signal SIGTRAP"
 
-    send_gdb "info signal 5\n"
-    gdb_expect {
-	-re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $" {
-	    pass "info signal 5"
-	}
-	-re "$gdb_prompt $" {
-	    fail "info signal 5"
-	}
-	timeout {
-	    fail "(timeout) info signal 5"
-	}
-    }
+    gdb_test "info signal 5" \
+	"SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*" \
+	"info signal 5"
 
     # Verify that "handle" with illegal arguments is gracefully, um,
     # handled.
 
-    send_gdb "handle\n"
-    gdb_expect {
-	-re "Argument required .signal to handle.*$gdb_prompt $" {
-	    pass "handle without arguments"
-	}
-	-re "$gdb_prompt $" {
-	    fail "handle without arguments"
-	}
-	timeout {
-	    fail "(timeout) handle without arguments"
-	}
-    }
+    gdb_test "handle" \
+	"Argument required .signal to handle.*" \
+	"handle without arguments"
 
-    send_gdb "handle SIGFOO\n"
-    gdb_expect {
-	-re "Unrecognized or ambiguous flag word: \"SIGFOO\".*$gdb_prompt $" {
-	    pass "handle with bogus SIG"
-	}
-	-re "$gdb_prompt $" {
-	    fail "handle with bogus SIG"
-	}
-	timeout {
-	    fail "(timeout) handle with bogus SIG"
-	}
-    }
+    gdb_test "handle SIGFOO" \
+	"Unrecognized or ambiguous flag word: \"SIGFOO\".*" \
+	"handle with bogus SIG"
 
-    send_gdb "handle SIGHUP frump\n"
-    gdb_expect {
-	-re "Unrecognized or ambiguous flag word: \"frump\".*$gdb_prompt $" {
-	    pass "handle SIG with bogus action"
-	}
-	-re "$gdb_prompt $" {
-	    fail "handle SIG with bogus action"
-	}
-	timeout {
-	    fail "(timeout) handle SIG with bogus action"
-	}
-    }
+    gdb_test "handle SIGHUP frump" \
+	"Unrecognized or ambiguous flag word: \"frump\".*" \
+	"handle SIG with bogus action"
 
     # Verify that "handle" can take multiple actions per SIG, and that
     # in the case of conflicting actions, that the rightmost action
     # "wins".
 
-    send_gdb "handle SIGHUP print noprint\n"
-    gdb_expect {
-	-re ".*SIGHUP\[ \t\]*No\[ \t\]*No\[ \t\]*Yes\[ \t\]*Hangup.*$gdb_prompt $" {
-	    pass "handle SIG with multiple conflicting actions"
-	}
-	-re "$gdb_prompt $" {
-	    fail "handle SIG with multiple conflicting actions"
-	}
-	timeout {
-	    fail "(timeout) handle SIG with multiple conflicting actions"
-	}
-    }
+    gdb_test "handle SIGHUP print noprint" \
+	"SIGHUP\[ \t\]*No\[ \t\]*No\[ \t\]*Yes\[ \t\]*Hangup.*" \
+	"handle SIG with multiple conflicting actions"
 
     # Exercise all the various actions.  (We don't care what the
     # outcome is, this is just to ensure that they all can be parsed.)
 
-    send_gdb "handle SIGHUP print noprint stop nostop ignore noignore pass nopass\n"
-    gdb_expect {
-	-re ".*Signal.*$gdb_prompt $" {
-	    pass "handle SIG parses all legal actions"
-	}
-	-re "$gdb_prompt $" {
-	    fail "handle SIG parses all legal actions"
-	}
-	timeout {
-	    fail "(timeout) handle SIG parses all legal actions"
-	}
-    }
+    gdb_test "handle SIGHUP print noprint stop nostop ignore noignore pass nopass" \
+	"Signal.*" \
+	"handle SIG parses all legal actions"
 
     # Verify that we can "handle" multiple signals at once,
     # interspersed with actions.
 
-    send_gdb "handle SIG63 print SIGILL\n"
-    gdb_expect {
-	-re ".*SIGILL\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Illegal instruction.*SIG63\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Real-time event 63.*$gdb_prompt $" {
-	    pass "handle multiple SIGs"
-	}
-	-re "$gdb_prompt $" {
-	    fail "handle multiple SIGs"
-	}
-	timeout {
-	    fail "(timeout) handle multiple SIGs"
-	}
-    }
+    gdb_test "handle SIG63 print SIGILL" \
+	"SIGILL\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Illegal instruction.*SIG63\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Real-time event 63.*" \
+	"handle multiple SIGs"
 
     # Verify that "handle" can take a numeric argument for the signal
     # ID, rather than a symbolic name.  (This may not be portable;
@@ -531,27 +300,12 @@ The program being debugged stopped while in a function called from GDB.*" \
     # at least, is used to implement single-steps and breakpoints.
     # Don't expect to run the inferior after this!
 
-    send_gdb "handle 5 nopass\n"
-    gdb_expect {
-	-re ".*SIGTRAP is used by the debugger.*Are you sure you want to change it.*y or n.*" {
-	    send_gdb "y\n"
-	    gdb_expect {
-		-re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $" {
-		    pass "override SIGTRAP (#5)"
-		}
-		-re "$gdb_prompt $" {
-		    fail "override SIGTRAP (#5)"
-		}
-		timeout {
-		    fail "(timeout) override SIGTRAP (#5)"
-		}
-	    }
-	}
-	-re "$gdb_prompt $" {
-	    fail "override SIGTRAP (#5)"
-	}
-	timeout {
-	    fail "(timeout) override SIGTRAP (#5)"
+    set test "override SIGTRAP"
+    gdb_test_multiple "handle 5 nopass" "$test" {
+	-re "SIGTRAP is used by the debugger.*Are you sure you want to change it.*y or n.*" {
+	    gdb_test "y" \
+		"SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*" \
+		"$test"
 	}
     }
 
@@ -559,116 +313,59 @@ The program being debugged stopped while in a function called from GDB.*" \
     # that restriction.  ??rehrauer: Not sure if this is a feature or a
     # bug, actually.  Why is the range 1-15?
 
-    send_gdb "handle 58\n"
-    gdb_expect {
-	-re "Only signals 1-15 are valid as numeric signals.*Use \"info signals\" for a list of symbolic signals.*$gdb_prompt $" {
-	    pass "invalid signal number rejected"
-	}
-	-re "$gdb_prompt $" {
-	    fail "invalid signal number rejected"
-	}
-	timeout {
-	    fail "(timeout) invalid signal number rejected"
-	}
-    }
+    gdb_test "handle 58" \
+	"Only signals 1-15 are valid as numeric signals.*Use \"info signals\" for a list of symbolic signals.*" \
+	"invalid signal number rejected"
 
     # Verify that we can accept a signal ID range (number-number).
     # ??rehrauer: This feature isn't documented on the quick-reference
     # card.
 
-    send_gdb "handle 13-15\n"
-    gdb_expect {
-	-re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $" {
-	    pass "handle multiple SIGs via integer range"
-	}
-	-re "$gdb_prompt $" {
-	    fail "handle multiple SIGs via integer range"
-	}
-	timeout {
-	    fail "(timeout) handle multiple SIGs via integer range"
-	}
-    }
+    gdb_test "handle 13-15" \
+	"SIGPIPE.*SIGALRM.*SIGTERM.*" \
+	"handle multiple SIGs via integer range"
 
     # Bizarrely enough, GDB also allows you to reverse the range stat,
     # stop IDs.  E.g., "3-1" and "1-3" mean the same thing.  Probably
     # this isn't documented, but the code anticipates it, so we'd best
     # test it...
 
-    send_gdb "handle 15-13\n"
-    gdb_expect {
-	-re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $" {
-	    pass "handle multiple SIGs via integer range"
-	}
-	-re "$gdb_prompt $" {
-	    fail "handle multiple SIGs via integer range"
-	}
-	timeout {
-	    fail "(timeout) handle multiple SIGs via integer range"
-	}
-    }
+    gdb_test "handle 15-13" \
+	"SIGPIPE.*SIGALRM.*SIGTERM.*" \
+	"handle multiple SIGs via reverse integer range"
 
     # SIGINT is used by the debugger as well.  Verify that we can
     # change our minds about changing it.
 
-    send_gdb "handle SIGINT nopass\n"
-    gdb_expect {
-	-re ".*SIGINT is used by the debugger.*Are you sure you want to change it.*y or n.*" {
-	    send_gdb "n\n"
-	    # ??rehrauer: When you answer "n", the header for the
-	    # signal info is printed, but not the actual handler
-	    # settings.  Probably a bug.
-	    gdb_expect {
-		-re "Not confirmed, unchanged.*Signal.*$gdb_prompt $" {
-		    pass "override SIGINT"
-		}
-		-re "$gdb_prompt $" {
-		    fail "override SIGINT"
+    set test "override SIGINT"
+    gdb_test_multiple "handle SIGINT nopass" "$test" {
+	-re "SIGINT is used by the debugger.*Are you sure you want to change it.*y or n.*" {
+	    gdb_test_multiple "n" "$test" {
+		-re "Not confirmed, unchanged.*Signal.*$gdb_prompt $"  {
+		    # "Signal ..." should not be in the output.
+		    kfail gdb/1707 "$test"
 		}
-		timeout {
-		    fail "(timeout) override SIGINT"
+		-re "Not confirmed, unchanged.*$gdb_prompt $" {
+		    pass "$test"
 		}
 	    }
 	}
-	-re "$gdb_prompt $" {
-	    fail "override SIGINT"
-	}
-	timeout {
-	    fail "(timeout) override SIGINT"
-	}
     }
 
     # Verify that GDB responds gracefully to the "signal" command with
     # a missing argument.
 
-    send_gdb "signal\n"
-    gdb_expect {
-	-re "Argument required .signal number..*$gdb_prompt $" {
-	    pass "signal without arguments disallowed"
-	}
-	-re "$gdb_prompt $" {
-	    fail "signal without arguments disallowed"
-	}
-	timeout {
-	    fail "(timeout) signal without arguments disallowed"
-	}
-    }
+    gdb_test "signal" \
+	"Argument required .signal number..*" \
+	"signal without arguments disallowed"
     
     # Verify that we can successfully send a signal other than 0 to
     # the inferior.  (This probably causes the inferior to run away.
     # Be prepared to rerun to main for further testing.)
 
-    send_gdb "signal 5\n"
-    gdb_expect {
-	-re "Continuing with signal SIGTRAP.*$gdb_prompt $" {
-	    pass "sent signal 5"
-	}
-	-re "$gdb_prompt $" {
-	    fail "sent signal 5"
-	}
-	timeout {
-	    fail "(timeout) sent signal 5"
-	}
-    }
+    gdb_test "signal 5" \
+	"Continuing with signal SIGTRAP.*" \
+	"sent signal 5"
 
 }