This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[commit] Overhaul signals.exp
- From: Andrew Cagney <cagney at gnu dot org>
- To: gdb-patches at sources dot redhat dot com
- Date: Mon, 12 Jul 2004 16:58:08 -0400
- Subject: [commit] Overhaul signals.exp
Hello,
This is the real overhaul of signals.exp. It:
- convert send_gdb / gdb_expect into gdb_test / gdb_test_multiple
- update test names to be unique and clearer
- update comments to reflect what the tests are doing
- delete many many bogus XFAILs
- add a KFAIL for an obvious bug.
Since I've been deleting XFAILs and adding KFAILs this affects test
result output. For instance, on x86_64 GNU/Linux, I see:
FAIL: gdb.base/signals.exp: continue to handler for 3rd alarm call (the
program exited)
FAIL: gdb.base/signals.exp: backtrace for 3rd alarm
KFAIL: gdb.base/signals.exp: override SIGINT (PRMS: gdb/1707)
The first was previously XFAILed. I suspect the problem is related to
gdb/1702 but I've not analyzed it. The behavior is definitly bogus.
The second is a cascading failure.
The third is a straight bug.
I'll give this a day.
Andrew
(the above are from testing on amd64 GNU/Linux)
2004-07-12 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.
Index: gdb.base/signals.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/signals.exp,v
retrieving revision 1.7
diff -p -u -r1.7 signals.exp
--- gdb.base/signals.exp 12 Jul 2004 15:02:52 -0000 1.7
+++ gdb.base/signals.exp 12 Jul 2004 20:42:38 -0000
@@ -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"
-
- # 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.
+ 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 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"
- }
- }
-
- 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 SIGTRAP" \
+ "SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*" \
+ "info signal SIGTRAP"
+
+ 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"
- }
- }
-
- 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"
- }
- }
-
- 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" \
+ "Argument required .signal to handle.*" \
+ "handle without arguments"
+
+ gdb_test "handle SIGFOO" \
+ "Unrecognized or ambiguous flag word: \"SIGFOO\".*" \
+ "handle with bogus SIG"
+
+ 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
# 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
# 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"
}