gdb/testsuite/gdb.base/signals.exp

   1 #   Copyright 1997, 1998, 1999 Free Software Foundation, Inc.
   2
   3 # This program is free software; you can redistribute it and/or modify
   4 # it under the terms of the GNU General Public License as published by
   5 # the Free Software Foundation; either version 2 of the License, or
   6 # (at your option) any later version.
   7 #
   8 # This program is distributed in the hope that it will be useful,
   9 # but WITHOUT ANY WARRANTY; without even the implied warranty of
  10 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  11 # GNU General Public License for more details.
  12 #
  13 # You should have received a copy of the GNU General Public License
  14 # along with this program; if not, write to the Free Software
  15 # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  16
  17 # Please email any bugs, comments, and/or additions to this file to:
  18 # bug-gdb@prep.ai.mit.edu
  19
  20 if [target_info exists gdb,nosignals] {
  21     verbose "Skipping signals.exp because of nosignals."
  22     continue
  23 }
  24
  25 if $tracelevel then {
  26         strace $tracelevel
  27 }
  28
  29 set prms_id 0
  30 set bug_id 0
  31
  32 set testfile signals
  33 set srcfile ${testfile}.c
  34 set binfile ${objdir}/${subdir}/${testfile}
  35 if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
  36      gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  37 }
  38
  39 # Create and source the file that provides information about the compiler
  40 # used to compile the test case.
  41 if [get_compiler_info ${binfile}] {
  42     return -1;
  43 }
  44
  45 if {$hp_cc_compiler} {
  46     set void 0
  47 } else {
  48     set void void
  49 }
  50
  51 proc signal_tests_1 {} {
  52     global gdb_prompt
  53     if [runto_main] then {
  54         gdb_test "next" "signal \\(SIGUSR1.*" \
  55                 "next over signal (SIGALRM, handler)"
  56         gdb_test "next" "alarm \\(.*" \
  57                 "next over signal (SIGUSR1, handler)"
  58         gdb_test "next" "\\+\\+count; /\\* first \\*/" \
  59                 "next over alarm (1)"
  60         # An alarm has been signaled, give the signal time to get delivered.
  61         sleep 2
  62
  63         # i386 BSD currently fails the next test with a SIGTRAP.
  64         setup_xfail "i*86-*-bsd*"
  65         # But Dynix has a DECR_PC_AFTER_BREAK of zero, so the failure
  66         # is shadowed by hitting the through_sigtramp_breakpoint.
  67         clear_xfail "i*86-sequent-bsd*"
  68         # Univel SVR4 i386 continues instead of stepping.
  69         setup_xfail "i*86-univel-sysv4*"
  70         # lynx fails with "next" acting like "continue"
  71         setup_xfail "*-*-*lynx*"
  72         # linux (aout versions) also fails with "next" acting like "continue"
  73         # this is probably more dependant on the kernel version than on the
  74         # object file format or utils.  (sigh)
  75         setup_xfail "i*86-pc-linuxaout-gnu" "i*86-pc-linuxoldld-gnu"
  76         send_gdb "next\n"
  77         gdb_expect {
  78             -re "alarm .*$gdb_prompt $" { pass "next to 2nd alarm (1)" }
  79             -re "Program received signal SIGTRAP.*first.*$gdb_prompt $" {
  80
  81                 # This can happen on machines that have a trace flag
  82                 # in their PS register.
  83                 # The trace flag in the PS register will be set due to
  84                 # the `next' command.
  85                 # Before calling the signal handler, the PS register
  86                 # is pushed along with the context on the user stack.
  87                 # When the signal handler has finished, it reenters the
  88                 # the kernel via a sigreturn syscall, which restores the
  89                 # PS register along with the context.
  90                 # If the kernel erroneously does not clear the trace flag
  91                 # in the pushed context, gdb will receive a SIGTRAP from
  92                 # the set trace flag in the restored context after the
  93                 # signal handler has finished.
  94
  95                 # I do not yet understand why the SIGTRAP does not occur
  96                 # after stepping the instruction at the restored PC on
  97                 # i386 BSDI 1.0 systems.
  98
  99                 # Note that the vax under Ultrix also exhibits
 100                 # this behaviour (it is uncovered by the `continue from
 101                 # a break in a signal handler' test below).
 102                 # With this test the failure is shadowed by hitting the
 103                 # through_sigtramp_breakpoint upon return from the signal
 104                 # handler.
 105
 106                 # SVR4 and Linux based i*86 systems exhibit this behaviour
 107                 # as well (it is uncovered by the `continue from a break
 108                 # in a signal handler' test below).
 109                 # As these systems use procfs, where we tell the kernel not
 110                 # to tell gdb about `pass' signals, and the trace flag is
 111                 # cleared by the kernel before entering the sigtramp
 112                 # routine, GDB will not notice the execution of the signal
 113                 # handler.
 114                 # Upon return from the signal handler, GDB will receive
 115                 # a SIGTRAP from the set trace flag in the restored context.
 116                 # The SIGTRAP marks the end of a (albeit long winded)
 117                 # single step for GDB, causing this test to pass.
 118
 119                 fail "next to 2nd alarm (1) (probably kernel bug)"
 120                 gdb_test "next" "alarm.*" "next to 2nd alarm (1)"
 121             }
 122             -re "Program exited with code.*$gdb_prompt $" {
 123
 124                 # This is apparently a bug in the UnixWare kernel (but
 125                 # has not been investigated beyond the
 126                 # resume/target_wait level, and has not been reported
 127                 # to Univel).  If it steps when a signal is pending,
 128                 # it does a continue instead.  I don't know whether
 129                 # there is a workaround.
 130
 131                 # Perhaps this problem exists on other SVR4 systems;
 132                 # but (a) we have no reason to think so, and (b) if we
 133                 # put a wrong xfail here, we never get an XPASS to let
 134                 # us know that it was incorrect (and then if such a
 135                 # configuration regresses we have no way of knowing).
 136                 # Solaris is not a relevant data point either way
 137                 # because it lacks single stepping.
 138
 139                 # fnf: I don't agree with the above philosophy.  We
 140                 # can never be sure that any particular XFAIL is
 141                 # specified 100% correctly in that no systems with
 142                 # the bug are missed and all systems without the bug
 143                 # are excluded.  If we include an XFAIL that isn't
 144                 # appropriate for a particular system, then when that
 145                 # system gets tested it will XPASS, and someone should
 146                 # investigate and fix the setup_xfail as appropriate,
 147                 # or more preferably, the actual bug.  Each such case
 148                 # adds more data to narrowing down the scope of the
 149                 # problem and ultimately fixing it.
 150
 151                 setup_xfail "i*86-*-sysv4*"
 152                 fail "'next' behaved as 'continue (known SVR4 bug)'"
 153                 return 0
 154             }
 155             -re ".*$gdb_prompt $" { fail "next to 2nd alarm (1)" }
 156             timeout { fail "next to 2nd alarm (1); (timeout)" }
 157             eof { fail "next to 2nd alarm (1); (eof)" }
 158         }
 159
 160         gdb_test "break handler" "Breakpoint \[0-9\]+ .*"
 161         gdb_test "next" "\\+\\+count; /\\* second \\*/" \
 162             "next to 2nd ++count in signals_tests_1"
 163         # An alarm has been signaled, give the signal time to get delivered.
 164         sleep 2
 165
 166         set bash_bug 0
 167         send_gdb "next\n"
 168         gdb_expect {
 169             -re "Breakpoint.*handler.*$gdb_prompt $" {
 170                 pass "next to handler in signals_tests_1"
 171             }
 172             -re "Program received signal SIGEMT.*$gdb_prompt $" {
 173                 # Bash versions before 1.13.5 cause this behaviour
 174                 # by blocking SIGTRAP.
 175                 fail "next to handler in signals_tests_1 (known problem with bash versions before 1.13.5)"
 176                 set bash_bug 1
 177                 gdb_test "signal 0" "Breakpoint.*handler.*"
 178             }
 179             -re ".*$gdb_prompt $" { fail "next to handler in signals_tests_1" }
 180             timeout { fail "next to handler in signals_tests_1 (timeout)" }
 181             eof { fail "next to handler in signals_tests_1 (eof)" }
 182         }
 183
 184         # This doesn't test that main is frame #2, just that main is frame
 185         # #2, #3, or higher.  At some point this should be fixed (but
 186         # it quite possibly would introduce new FAILs on some systems).
 187         setup_xfail "i*86-*-bsdi2.0"
 188         gdb_test "backtrace 10" "#0.*handler.*#1.*#2.*main.*" \
 189             "backtrace in signals_tests_1"
 190
 191         gdb_test "break func1" "Breakpoint \[0-9\]+ .*"
 192         gdb_test "break func2" "Breakpoint \[0-9\]+ .*"
 193
 194         # Vax Ultrix and i386 BSD currently fail the next test with
 195         # a SIGTRAP, but with different symptoms.
 196         setup_xfail "vax-*-ultrix*"
 197         setup_xfail "i*86-*-bsd*"
 198         setup_xfail "i*86-pc-linux-gnu*"
 199         setup_xfail "i*86-*-solaris2*"
 200         send_gdb "continue\n"
 201         gdb_expect {
 202             -re "Breakpoint.*func1.*$gdb_prompt $" { pass "continue to func1" }
 203             -re "Program received signal SIGTRAP.*second.*$gdb_prompt $" {
 204
 205                 # See explanation for `next to 2nd alarm (1)' fail above.
 206                 # We did step into the signal handler, hit a breakpoint
 207                 # in the handler and continued from the breakpoint.
 208                 # The set trace flag in the restored context is causing
 209                 # the SIGTRAP, without stepping an instruction.
 210
 211                 fail "continue to func1 (probably kernel bug)"
 212                 gdb_test "continue" "Breakpoint.*func1.*" \
 213                     "extra continue to func1"
 214             }
 215             -re "Program received signal SIGTRAP.*func1 ..;.*$gdb_prompt $" {
 216
 217                 # On the vax under Ultrix the set trace flag in the restored
 218                 # context is causing the SIGTRAP, but after stepping one
 219                 # instruction, as expected.
 220
 221                 fail "continue to func1 (probably kernel bug)"
 222                 gdb_test "continue" "Breakpoint.*func1.*" \
 223                     "extra continue to func1"
 224             }
 225             -re ".*$gdb_prompt $" { fail "continue to func1" }
 226             default { fail "continue to func1" }
 227         }
 228
 229         setup_xfail "*-*-irix*"
 230         send_gdb "signal SIGUSR1\n"
 231         gdb_expect {
 232             -re "Breakpoint.*handler.*$gdb_prompt $" { pass "signal SIGUSR1" }
 233             -re "Program received signal SIGUSR1.*$gdb_prompt $" {
 234                 # This is what irix4 and irix5 do.
 235                 # It would appear to be a kernel bug.
 236                 fail "signal SIGUSR1"
 237                 gdb_test "continue" "Breakpoint.*handler.*" "pass it SIGUSR1"
 238             }
 239             -re ".*$gdb_prompt $" { fail "signal SIGUSR1" }
 240             default { fail "signal SIGUSR1" }
 241         }
 242
 243         # Will tend to wrongly require an extra continue.
 244
 245         # The problem here is that the breakpoint at func1 will be
 246         # inserted, and when the system finishes with the signal
 247         # handler it will try to execute there.  For GDB to try to
 248         # remember that it was going to step over a breakpoint when a
 249         # signal happened, distinguish this case from the case where
 250         # func1 is called from the signal handler, etc., seems
 251         # exceedingly difficult.  So don't expect this to get fixed
 252         # anytime soon.
 253
 254         setup_xfail "*-*-*"
 255         send_gdb "continue\n"
 256         gdb_expect {
 257             -re "Breakpoint.*func2.*$gdb_prompt $" { pass "continue to func2" }
 258             -re "Breakpoint.*func1.*$gdb_prompt $" {
 259                 fail "continue to func2"
 260                 gdb_test "continue" "Breakpoint.*func2.*" \
 261                     "extra continue to func2"
 262             }
 263             -re ".*$gdb_prompt $" { fail "continue to func2" }
 264             default { fail "continue to func2" }
 265         }
 266
 267         sleep 2
 268
 269         # GDB yanks out the breakpoints to step over the breakpoint it
 270         # stopped at, which means the breakpoint at handler is yanked.
 271         # But if SOFTWARE_SINGLE_STEP_P, we won't get another chance to
 272         # reinsert them (at least not with procfs, where we tell the kernel
 273         # not to tell gdb about `pass' signals).  So the fix would appear to
 274         # be to just yank that one breakpoint when we step over it.
 275
 276         setup_xfail "sparc*-*-*"
 277         setup_xfail "rs6000-*-*"
 278         setup_xfail "powerpc-*-*"
 279
 280         # A faulty bash will not step the inferior into sigtramp on sun3.
 281         if {$bash_bug} then {
 282             setup_xfail "m68*-*-sunos4*"
 283         }
 284
 285         setup_xfail "i*86-pc-linux-gnu*"
 286         setup_xfail "i*86-*-solaris2*"
 287         gdb_test "continue" "Breakpoint.*handler.*" "continue to handler"
 288
 289         # If the SOFTWARE_SINGLE_STEP_P failure happened, we have already
 290         # exited.
 291         # If we succeeded a continue will return from the handler to func2.
 292         # GDB now has `forgotten' that it intended to step over the
 293         # breakpoint at func2 and will stop at func2.
 294         setup_xfail "*-*-*"
 295         # The sun3 with a faulty bash will also be `forgetful' but it
 296         # already got the spurious stop at func2 and this continue will work.
 297         if {$bash_bug} then {
 298              clear_xfail "m68*-*-sunos4*"
 299         }
 300         gdb_test "continue" "Program exited with code 010\\." \
 301             "continue to exit in signals_tests_1 "
 302     }
 303 }
 304
 305 # On a few losing systems, ptrace (PT_CONTINUE) or ptrace (PT_STEP)
 306 # causes pending signals to be cleared, which causes these tests to
 307 # get nowhere fast.  This is totally losing behavior (perhaps there
 308 # are cases in which is it useful but the user needs more control,
 309 # which they mostly have in GDB), but some people apparently think it
 310 # is a feature.  It is documented in the ptrace manpage on Motorola
 311 # Delta Series sysV68 R3V7.1 and on HPUX 9.0.  Even the non-HPUX PA
 312 # OSes (BSD and OSF/1) seem to have figured they had to copy this
 313 # braindamage.
 314
 315 if {[ istarget "m68*-motorola-*" ] || [ istarget "hppa*-*-bsd*" ] ||
 316     [ istarget "hppa*-*-osf*" ]} then {
 317   setup_xfail "*-*-*"
 318   fail "ptrace loses on signals on this target"
 319   return 0
 320 }
 321
 322 # lynx2.2.2 doesn't lose signals, instead it screws up the stack pointer
 323 # in some of these tests leading to massive problems.  I've
 324 # reported this to lynx, hopefully it'll be fixed in lynx2.3.
 325 # Severe braindamage.
 326 if [ istarget "*-*-*lynx*" ] then {
 327   setup_xfail "*-*-*"
 328   fail "kernel scroggs stack pointer in signal tests on this target"
 329   return 0
 330 }
 331
 332 gdb_exit
 333 gdb_start
 334
 335 # This will need to be updated as the exact list of signals changes,
 336 # but I want to test that TARGET_SIGNAL_0, TARGET_SIGNAL_DEFAULT, and
 337 # TARGET_SIGNAL_UNKNOWN are skipped.
 338 proc test_handle_all_print {} {
 339     global timeout
 340     # Increase timeout and expect input buffer for large output from gdb.
 341     # Allow blank or TAB as whitespace characters.
 342     set oldtimeout $timeout
 343     set timeout [expr "$timeout + 360"]
 344     verbose "Timeout is now $timeout seconds" 2
 345     if { ![istarget "*-*-linux*"]
 346          && ( [istarget "*-*-gnu*"]
 347               || [istarget "*-*-mach*"] ) } {
 348         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"
 349     } else {
 350         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.*"
 351     }
 352     set timeout $oldtimeout
 353     verbose "Timeout restored to $timeout seconds" 2
 354 }
 355 test_handle_all_print
 356
 357 gdb_exit
 358 gdb_start
 359 gdb_reinitialize_dir $srcdir/$subdir
 360 gdb_load $binfile
 361 signal_tests_1
 362
 363 # Force a resync, so we're looking at the right prompt.  On SCO we
 364 # were getting out of sync (I don't understand why).
 365 send_gdb "p 1+1\n"
 366 gdb_expect {
 367     -re "= 2.*$gdb_prompt $" {}
 368     -re ".*$gdb_prompt $" { perror "sync trouble in signals.exp" }
 369     default { perror "sync trouble in signals.exp" }
 370 }
 371
 372 if [runto_main] then {
 373     # Since count is a static variable outside main, runto_main
 374     # is no guarantee that count will be 0 at this point.
 375     gdb_test "set variable count = 0" ""
 376     gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*"
 377     gdb_test "set \$handler_breakpoint_number = \$bpnum" ""
 378
 379     # Get to the point where a signal is waiting to be delivered
 380     gdb_test "next" "signal \\(SIGUSR1.*" "next to signal in signals.exp"
 381     gdb_test "next" "alarm \\(.*" "next to alarm #1 in signals.exp"
 382     gdb_test "next" "\\+\\+count; /\\* first \\*/" \
 383         "next to ++count #1 in signals.exp"
 384     # Give the signal time to get delivered
 385     sleep 2
 386
 387     # Now call a function.  When GDB tries to run the stack dummy,
 388     # it will hit the breakpoint at handler.  Provided it doesn't
 389     # lose its cool, this is not a problem, it just has to note
 390     # that the breakpoint condition is false and keep going.
 391
 392     gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = $void" \
 393         "p func1 () #1 in signals.exp"
 394
 395     # Make sure the count got incremented.
 396
 397     # Haven't investigated this xfail
 398     setup_xfail "rs6000-*-*"
 399     setup_xfail "powerpc-*-*"
 400     gdb_test "p count" "= 2" "p count #1 in signals.exp"
 401     if { [istarget "rs6000-*-*"] || [istarget "powerpc-*-*"] } { return 0 }
 402
 403     gdb_test "condition \$handler_breakpoint_number" "now unconditional\\."
 404     gdb_test "next" "alarm \\(.*" "next to alarm #2 in signals.exp"
 405     gdb_test "next" "\\+\\+count; /\\* second \\*/" \
 406         "next to ++count #2 in signals.exp"
 407     sleep 2
 408
 409     # This time we stop when GDB tries to run the stack dummy.
 410     # So it is OK that we do not print the return value from the function.
 411     gdb_test "p func1 ()" \
 412 "Breakpoint \[0-9\]*, handler.*
 413 The program being debugged stopped while in a function called from GDB.*" \
 414         "p func1 () #2 in signals.exp"
 415     # But we should be able to backtrace...
 416     # On alpha-*-osf2.0 this test works when run manually but sometime fails when
 417     # run under dejagnu, making it very hard to debug the problem.  Weird...
 418     gdb_test "bt 10" "#0.*handler.*#1.*#2.*main.*" "bt in signals.exp"
 419     # ...and continue...
 420     gdb_test "continue" "Continuing\\." "continue in signals.exp"
 421     # ...and then count should have been incremented
 422     gdb_test "p count" "= 5" "p count #2 in signals.exp"
 423
 424
 425 # Verify that "info signals" produces reasonable output.
 426 #
 427     send_gdb "info signals\n"
 428     gdb_expect {
 429       -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 $"\
 430               {pass "info signals"}
 431       -re "$gdb_prompt $"\
 432               {fail "info signals"}
 433       timeout {fail "(timeout) info signals"}
 434     }
 435
 436 # Verify that "info signal" correctly handles an argument, be it a
 437 # symbolic signal name, or an integer ID.
 438 #
 439     send_gdb "info signal SIGTRAP\n"
 440     gdb_expect {
 441       -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\
 442               {pass "info signal SIGTRAP"}
 443       -re "$gdb_prompt $"\
 444               {fail "info signal SIGTRAP"}
 445       timeout {fail "(timeout) info signal SIGTRAP"}
 446     }
 447
 448     send_gdb "info signal 5\n"
 449     gdb_expect {
 450       -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\
 451               {pass "info signal 5"}
 452       -re "$gdb_prompt $"\
 453               {fail "info signal 5"}
 454       timeout {fail "(timeout) info signal 5"}
 455     }
 456
 457 # Verify that "handle" with illegal arguments is gracefully, um, handled.
 458 #
 459     send_gdb "handle\n"
 460     gdb_expect {
 461       -re "Argument required .signal to handle.*$gdb_prompt $"\
 462               {pass "handle without arguments"}
 463       -re "$gdb_prompt $"\
 464               {fail "handle without arguments"}
 465       timeout {fail "(timeout) handle without arguments"}
 466     }
 467
 468     send_gdb "handle SIGFOO\n"
 469     gdb_expect {
 470       -re "Unrecognized or ambiguous flag word: \"SIGFOO\".*$gdb_prompt $"\
 471               {pass "handle with bogus SIG"}
 472       -re "$gdb_prompt $"\
 473               {fail "handle with bogus SIG"}
 474       timeout {fail "(timeout) handle with bogus SIG"}
 475     }
 476
 477     send_gdb "handle SIGHUP frump\n"
 478     gdb_expect {
 479       -re "Unrecognized or ambiguous flag word: \"frump\".*$gdb_prompt $"\
 480               {pass "handle SIG with bogus action"}
 481       -re "$gdb_prompt $"\
 482               {fail "handle SIG with bogus action"}
 483       timeout {fail "(timeout) handle SIG with bogus action"}
 484     }
 485
 486 # Verify that "handle" can take multiple actions per SIG, and that in
 487 # the case of conflicting actions, that the rightmost action "wins".
 488 #
 489     send_gdb "handle SIGHUP print noprint\n"
 490     gdb_expect {
 491       -re ".*SIGHUP\[ \t\]*No\[ \t\]*No\[ \t\]*Yes\[ \t\]*Hangup.*$gdb_prompt $"\
 492               {pass "handle SIG with multiple conflicting actions"}
 493       -re "$gdb_prompt $"\
 494               {fail "handle SIG with multiple conflicting actions"}
 495       timeout {fail "(timeout) handle SIG with multiple conflicting actions"}
 496     }
 497
 498 # Exercise all the various actions.  (We don't care what the outcome
 499 # is, this is just to ensure that they all can be parsed.)
 500 #
 501     send_gdb "handle SIGHUP print noprint stop nostop ignore noignore pass nopass\n"
 502     gdb_expect {
 503       -re ".*Signal.*$gdb_prompt $"\
 504               {pass "handle SIG parses all legal actions"}
 505       -re "$gdb_prompt $"\
 506               {fail "handle SIG parses all legal actions"}
 507       timeout {fail "(timeout) handle SIG parses all legal actions"}
 508     }
 509
 510 # Verify that we can "handle" multiple signals at once, interspersed
 511 # with actions.
 512 #
 513     send_gdb "handle SIG63 print SIGILL\n"
 514     gdb_expect {
 515       -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 $"\
 516               {pass "handle multiple SIGs"}
 517       -re "$gdb_prompt $"\
 518               {fail "handle multiple SIGs"}
 519       timeout {fail "(timeout) handle multiple SIGs"}
 520     }
 521
 522 # Verify that "handle" can take a numeric argument for the signal ID,
 523 # rather than a symbolic name.  (This may not be portable; works for
 524 # HP-UX.)
 525 #
 526 # Also note that this testpoint overrides SIGTRAP, which on HP-UX at
 527 # least, is used to implement single-steps and breakpoints.  Don't
 528 # expect to run the inferior after this!
 529 #
 530     send_gdb "handle 5 nopass\n"
 531     gdb_expect {
 532       -re ".*SIGTRAP is used by the debugger.*Are you sure you want to change it.*y or n.*"\
 533               {send_gdb "y\n"
 534                gdb_expect {
 535                  -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\
 536                          {pass "override SIGTRAP (#5)"}
 537                  -re "$gdb_prompt $"\
 538                          {fail "override SIGTRAP (#5)"}
 539                  timeout {fail "(timeout) override SIGTRAP (#5)"}
 540                }
 541               }
 542       -re "$gdb_prompt $"\
 543               {fail "override SIGTRAP (#5)"}
 544       timeout {fail "(timeout) override SIGTRAP (#5)"}
 545     }
 546
 547 # GDB doesn't seem to allow numeric signal IDs larger than 15.  Verify
 548 # that restriction.  ??rehrauer: Not sure if this is a feature or a
 549 # bug, actually.  Why is the range 1-15?
 550 #
 551     send_gdb "handle 58\n"
 552     gdb_expect {
 553       -re "Only signals 1-15 are valid as numeric signals.*Use \"info signals\" for a list of symbolic signals.*$gdb_prompt $"\
 554               {pass "invalid signal number rejected"}
 555       -re "$gdb_prompt $"\
 556               {fail "invalid signal number rejected"}
 557       timeout {fail "(timeout) invalid signal number rejected"}
 558     }
 559
 560 # Verify that we can accept a signal ID range (number-number).
 561 # ??rehrauer: This feature isn't documented on the quick-reference
 562 # card.
 563 #
 564     send_gdb "handle 13-15\n"
 565     gdb_expect {
 566       -re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $"\
 567               {pass "handle multiple SIGs via integer range"}
 568       -re "$gdb_prompt $"\
 569               {fail "handle multiple SIGs via integer range"}
 570       timeout {fail "(timeout) handle multiple SIGs via integer range"}
 571
 572     }
 573
 574 # Bizarrely enough, GDB also allows you to reverse the range
 575 # stat, stop IDs.  E.g., "3-1" and "1-3" mean the same thing.
 576 # Probably this isn't documented, but the code anticipates it,
 577 # so we'd best test it...
 578 #
 579     send_gdb "handle 15-13\n"
 580     gdb_expect {
 581       -re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $"\
 582               {pass "handle multiple SIGs via integer range"}
 583       -re "$gdb_prompt $"\
 584               {fail "handle multiple SIGs via integer range"}
 585       timeout {fail "(timeout) handle multiple SIGs via integer range"}
 586
 587     }
 588
 589 # SIGINT is used by the debugger as well.  Verify that we can change
 590 # our minds about changing it.
 591 #
 592     send_gdb "handle SIGINT nopass\n"
 593     gdb_expect {
 594       -re ".*SIGINT is used by the debugger.*Are you sure you want to change it.*y or n.*"\
 595               {send_gdb "n\n"
 596 # ??rehrauer: When you answer "n", the header for the signal info is
 597 # printed, but not the actual handler settings.  Probably a bug.
 598 #
 599                gdb_expect {
 600                  -re "Not confirmed, unchanged.*Signal.*$gdb_prompt $"\
 601                          {pass "override SIGINT"}
 602                  -re "$gdb_prompt $"\
 603                          {fail "override SIGINT"}
 604                  timeout {fail "(timeout) override SIGINT"}
 605                }
 606               }
 607       -re "$gdb_prompt $"\
 608               {fail "override SIGINT"}
 609       timeout {fail "(timeout) override SIGINT"}
 610     }
 611
 612 # Verify that GDB responds gracefully to the "signal" command with
 613 # a missing argument.
 614 #
 615     send_gdb "signal\n"
 616     gdb_expect {
 617       -re "Argument required .signal number..*$gdb_prompt $"\
 618               {pass "signal without arguments disallowed"}
 619       -re "$gdb_prompt $"\
 620               {fail "signal without arguments disallowed"}
 621       timeout {fail "(timeout) signal without arguments disallowed"}
 622     }
 623
 624 # Verify that we can successfully send a signal other than 0 to
 625 # the inferior.  (This probably causes the inferior to run away.
 626 # Be prepared to rerun to main for further testing.)
 627 #
 628     send_gdb "signal 5\n"
 629     gdb_expect {
 630       -re "Continuing with signal SIGTRAP.*$gdb_prompt $"\
 631               {pass "sent signal 5"}
 632       -re "$gdb_prompt $"\
 633               {fail "sent signal 5"}
 634       timeout {fail "(timeout) sent signal 5"}
 635     }
 636
 637 }
 638
 639 return 0