# 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 # 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. 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; } if {$hp_cc_compiler} { set void 0 } else { 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 # 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" 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\]+ .*" # 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" } } # 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 "*-*-linux*"] && ( [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 { # 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" "" 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.*signal handler.*#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