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