diff options
Diffstat (limited to 'gnu/usr.bin/binutils/gdb/testsuite/gdb.base/signals.exp')
| -rw-r--r-- | gnu/usr.bin/binutils/gdb/testsuite/gdb.base/signals.exp | 678 |
1 files changed, 157 insertions, 521 deletions
diff --git a/gnu/usr.bin/binutils/gdb/testsuite/gdb.base/signals.exp b/gnu/usr.bin/binutils/gdb/testsuite/gdb.base/signals.exp index a07e3a8500a..cbe00bf3b12 100644 --- a/gnu/usr.bin/binutils/gdb/testsuite/gdb.base/signals.exp +++ b/gnu/usr.bin/binutils/gdb/testsuite/gdb.base/signals.exp @@ -1,4 +1,4 @@ -# Copyright 1997, 1998, 1999, 2003 Free Software Foundation, Inc. +# Copyright 1997, 1998, 1999, 2003, 2004 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 @@ -14,9 +14,6 @@ # 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 @@ -33,7 +30,7 @@ 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." + 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 @@ -48,294 +45,13 @@ if {$hp_cc_compiler} { set void void } -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-*-bsdi2.0" - gdb_test "backtrace 10" "#0.*handler.*#1.*signal handler.*#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-*-freebsd*" - 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. @@ -359,282 +75,202 @@ 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 { - # Since count is a static variable outside main, runto_main - # is no guarantee that count will be 0 at this point. + + # 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 - gdb_test "next" "signal \\(SIGUSR1.*" "next to signal in signals.exp" - gdb_test "next" "alarm \\(.*" "next to alarm #1 in signals.exp" + # ...setup the signal + + 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" + + # ...veryfiy that the cout was updated - # Make sure the count got incremented. + gdb_test "p count" "= 2" "p count #1" - # 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 } + # 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" - # 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.*signal handler.*#2.* main .*" "bt in signals.exp" - # ...and continue... - gdb_test "continue" "Continuing\\." "continue in signals.exp" + "p func1 () #2" + + # ...verify the backtrace + + 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 (silently returning) + + gdb_test "continue" "Continuing\\." + # ...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"} - } + gdb_test "p count" "= 5" "p count #2" - 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"} - } + # Verify that "info signals" produces reasonable output. - 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 "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" - 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 "info signal" correctly handles an argument, be it a + # symbolic signal name, or an integer ID. -# 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 "info signal SIGTRAP" \ + "SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*" \ + "info signal SIGTRAP" -# 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 "info signal 5" \ + "SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*" \ + "info signal 5" -# 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" with illegal arguments is gracefully, um, + # handled. -# 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_test "handle" \ + "Argument required .signal to handle.*" \ + "handle without arguments" -# 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"} - } + gdb_test "handle SIGFOO" \ + "Unrecognized or ambiguous flag word: \"SIGFOO\".*" \ + "handle with bogus SIG" -# 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 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". -# 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 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.) -# 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"} - } + 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. + + 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; + # works for HP-UX.) -# 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"} + # 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! + + 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" + } } -# 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 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? + + 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. + + 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... + + 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. + + 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" + } + -re "Not confirmed, unchanged.*$gdb_prompt $" { + pass "$test" + } + } + } } + # Verify that GDB responds gracefully to the "signal" command with + # a missing argument. + + 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.) + + gdb_test "signal SIGUSR1" "Breakpoint.*handler.*" + gdb_test "bt" \ + "#0 handler .*#1 .signal handler called.*\#2 .*main.*" \ + "backtrace for SIGUSR1" } return 0 |