gdb/testsuite/gdb.base/signals.exp

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