diff options
Diffstat (limited to 'gdb/testsuite/gdb.base/signals.exp')
| -rw-r--r-- | gdb/testsuite/gdb.base/signals.exp | 628 |
1 files changed, 628 insertions, 0 deletions
diff --git a/gdb/testsuite/gdb.base/signals.exp b/gdb/testsuite/gdb.base/signals.exp new file mode 100644 index 00000000000..49bf49081b0 --- /dev/null +++ b/gdb/testsuite/gdb.base/signals.exp @@ -0,0 +1,628 @@ +# Copyright (C) 1997, 1998 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +# Please email any bugs, comments, and/or additions to this file to: +# bug-gdb@prep.ai.mit.edu + +if [target_info exists gdb,nosignals] { + verbose "Skipping signals.exp because of nosignals." + continue +} + +if $tracelevel then { + strace $tracelevel +} + +set prms_id 0 +set bug_id 0 + +set testfile signals +set srcfile ${testfile}.c +set binfile ${objdir}/${subdir}/${testfile} +if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } { + gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." +} + +# Create and source the file that provides information about the compiler +# used to compile the test case. +if [get_compiler_info ${binfile}] { + return -1; +} + +proc signal_tests_1 {} { + global gdb_prompt + if [runto_main] then { + gdb_test "next" "signal \\(SIGUSR1.*" \ + "next over signal (SIGALRM, handler)" + gdb_test "next" "alarm \\(.*" \ + "next over signal (SIGUSR1, handler)" + gdb_test "next" "\\+\\+count; /\\* first \\*/" \ + "next over alarm (1)" + # An alarm has been signaled, give the signal time to get delivered. + sleep 2 + + # i386 BSD currently fails the next test with a SIGTRAP. + setup_xfail "i*86-*-bsd*" + # But Dynix has a DECR_PC_AFTER_BREAK of zero, so the failure + # is shadowed by hitting the through_sigtramp_breakpoint. + clear_xfail "i*86-sequent-bsd*" + # Univel SVR4 i386 continues instead of stepping. + setup_xfail "i*86-univel-sysv4*" + # lynx fails with "next" acting like "continue" + setup_xfail "*-*-*lynx*" + # linux (aout versions) also fails with "next" acting like "continue" + # this is probably more dependant on the kernel version than on the + # object file format or utils. (sigh) + setup_xfail "i*86-pc-linuxaout-gnu" "i*86-pc-linuxoldld-gnu" + send_gdb "next\n" + gdb_expect { + -re "alarm .*$gdb_prompt $" { pass "next to 2nd alarm (1)" } + -re "Program received signal SIGTRAP.*first.*$gdb_prompt $" { + + # 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. + + fail "next to 2nd alarm (1) (probably kernel bug)" + gdb_test "next" "alarm.*" "next to 2nd alarm (1)" + } + -re "Program exited with code.*$gdb_prompt $" { + + # This is apparently a bug in the UnixWare kernel (but + # has not been investigated beyond the + # resume/target_wait level, and has not been reported + # to Univel). If it steps when a signal is pending, + # it does a continue instead. I don't know whether + # there is a workaround. + + # Perhaps this problem exists on other SVR4 systems; + # but (a) we have no reason to think so, and (b) if we + # put a wrong xfail here, we never get an XPASS to let + # us know that it was incorrect (and then if such a + # configuration regresses we have no way of knowing). + # Solaris is not a relevant data point either way + # because it lacks single stepping. + + # fnf: I don't agree with the above philosophy. We + # can never be sure that any particular XFAIL is + # specified 100% correctly in that no systems with + # the bug are missed and all systems without the bug + # are excluded. If we include an XFAIL that isn't + # appropriate for a particular system, then when that + # system gets tested it will XPASS, and someone should + # investigate and fix the setup_xfail as appropriate, + # or more preferably, the actual bug. Each such case + # adds more data to narrowing down the scope of the + # problem and ultimately fixing it. + + setup_xfail "i*86-*-sysv4*" + fail "'next' behaved as 'continue (known SVR4 bug)'" + return 0 + } + -re ".*$gdb_prompt $" { fail "next to 2nd alarm (1)" } + timeout { fail "next to 2nd alarm (1); (timeout)" } + eof { fail "next to 2nd alarm (1); (eof)" } + } + + 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. + sleep 2 + + 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-pc-linux-gnu*" "i*86-*-bsdi2.0" + gdb_test "backtrace 10" "#0.*handler.*#1.*#2.*main.*" \ + "backtrace in signals_tests_1" + + gdb_test "break func1" "Breakpoint \[0-9\]+ .*" + gdb_test "break func2" "Breakpoint \[0-9\]+ .*" + + # Vax Ultrix and i386 BSD currently fail the next test with + # a SIGTRAP, but with different symptoms. + setup_xfail "vax-*-ultrix*" + setup_xfail "i*86-*-bsd*" + setup_xfail "i*86-pc-linux-gnu*" + setup_xfail "i*86-*-solaris2*" + send_gdb "continue\n" + gdb_expect { + -re "Breakpoint.*func1.*$gdb_prompt $" { pass "continue to func1" } + -re "Program received signal SIGTRAP.*second.*$gdb_prompt $" { + + # See explanation for `next to 2nd alarm (1)' fail above. + # We did step into the signal handler, hit a breakpoint + # in the handler and continued from the breakpoint. + # The set trace flag in the restored context is causing + # the SIGTRAP, without stepping an instruction. + + fail "continue to func1 (probably kernel bug)" + gdb_test "continue" "Breakpoint.*func1.*" \ + "extra continue to func1" + } + -re "Program received signal SIGTRAP.*func1 ..;.*$gdb_prompt $" { + + # On the vax under Ultrix the set trace flag in the restored + # context is causing the SIGTRAP, but after stepping one + # instruction, as expected. + + fail "continue to func1 (probably kernel bug)" + gdb_test "continue" "Breakpoint.*func1.*" \ + "extra continue to func1" + } + -re ".*$gdb_prompt $" { fail "continue to func1" } + default { fail "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" } + } + + # Will tend to wrongly require an extra continue. + + # The problem here is that the breakpoint at func1 will be + # inserted, and when the system finishes with the signal + # handler it will try to execute there. For GDB to try to + # remember that it was going to step over a breakpoint when a + # signal happened, distinguish this case from the case where + # func1 is called from the signal handler, etc., seems + # exceedingly difficult. So don't expect this to get fixed + # anytime soon. + + setup_xfail "*-*-*" + send_gdb "continue\n" + gdb_expect { + -re "Breakpoint.*func2.*$gdb_prompt $" { pass "continue to func2" } + -re "Breakpoint.*func1.*$gdb_prompt $" { + fail "continue to func2" + gdb_test "continue" "Breakpoint.*func2.*" \ + "extra continue to func2" + } + -re ".*$gdb_prompt $" { fail "continue to func2" } + default { fail "continue to func2" } + } + + sleep 2 + + # 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. + 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*" + } + 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 + +# This will need to be updated as the exact list of signals changes, +# but I want to test that TARGET_SIGNAL_0, TARGET_SIGNAL_DEFAULT, and +# TARGET_SIGNAL_UNKNOWN are skipped. +proc test_handle_all_print {} { + global timeout + # Increase timeout and expect input buffer for large output from gdb. + # Allow blank or TAB as whitespace characters. + set oldtimeout $timeout + set timeout [expr "$timeout + 360"] + verbose "Timeout is now $timeout seconds" 2 + if { [istarget "*-*-gnu*"] || [istarget "*-*-mach*"] } { + gdb_test "handle all print" "Signal\[ \]+Stop\[ \]+Print\[ \]+Pass to program\[ \]+Description\r\nSIGHUP\[ \]+Yes\[ \]+Yes\[ \]+Yes\[ \]+Hangup.*SIG63\[ \]+Yes\[ \]+Yes\[ \]+Yes\[ \]+Real-time event 63.*EXC_BREAKPOINT\[ \]+Yes\[ \]+Yes\[ \]+Yes\[ \]+Breakpoint" + } else { + gdb_test "handle all print" "Signal\[ \]+Stop\[ \]+Print\[ \]+Pass to program\[ \]+Description\r\nSIGHUP\[ \]+Yes\[ \]+Yes\[ \]+Yes\[ \]+Hangup.*SIG63\[ \]+Yes\[ \]+Yes\[ \]+Yes\[ \]+Real-time event 63" + } + set timeout $oldtimeout + verbose "Timeout restored to $timeout seconds" 2 +} +test_handle_all_print + +gdb_exit +gdb_start +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 { + 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 + 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" "\\+\\+count; /\\* first \\*/" \ + "next to ++count #1 in signals.exp" + # Give the signal time to get delivered + 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. + + gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = void" \ + "p func1 () #1 in signals.exp" + + # Make sure the count got incremented. + + # Haven't investigated this xfail + setup_xfail "rs6000-*-*" + setup_xfail "powerpc-*-*" + gdb_test "p count" "= 2" "p count #1 in signals.exp" + if { [istarget "rs6000-*-*"] || [istarget "powerpc-*-*"] } { return 0 } + + gdb_test "condition \$handler_breakpoint_number" "now unconditional\\." + gdb_test "next" "alarm \\(.*" "next to alarm #2 in signals.exp" + gdb_test "next" "\\+\\+count; /\\* second \\*/" \ + "next to ++count #2 in signals.exp" + 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. + 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" + # 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... + gdb_test "bt 10" "#0.*handler.*#1.*#2.*main.*" "bt in signals.exp" + # ...and continue... + gdb_test "continue" "Continuing\\." "continue in signals.exp" + # ...and then count should have been incremented + gdb_test "p count" "= 5" "p count #2 in signals.exp" + + +# 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"} + } + +# 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"} + } + +# 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"} + } + +# 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"} + } + +# 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"} + } + +# 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"} + } + +# Verify that "handle" can take a numeric argument for the signal ID, +# rather than a symbolic name. (This may not be portable; works for +# HP-UX.) +# +# Also note that this testpoint overrides SIGTRAP, which on HP-UX 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)"} + } + +# GDB doesn't seem to allow numeric signal IDs larger than 15. Verify +# 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"} + } + +# 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"} + + } + +# 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"} + + } + +# 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"} + timeout {fail "(timeout) override SIGINT"} + } + } + -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"} + } + +# 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"} + } + +} + +return 0 |