| 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 | gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*" |
| 374 | gdb_test "set \$handler_breakpoint_number = \$bpnum" "" |
| 375 | |
| 376 | # Get to the point where a signal is waiting to be delivered |
| 377 | gdb_test "next" "signal \\(SIGUSR1.*" "next to signal in signals.exp" |
| 378 | gdb_test "next" "alarm \\(.*" "next to alarm #1 in signals.exp" |
| 379 | gdb_test "next" "\\+\\+count; /\\* first \\*/" \ |
| 380 | "next to ++count #1 in signals.exp" |
| 381 | # Give the signal time to get delivered |
| 382 | sleep 2 |
| 383 | |
| 384 | # Now call a function. When GDB tries to run the stack dummy, |
| 385 | # it will hit the breakpoint at handler. Provided it doesn't |
| 386 | # lose its cool, this is not a problem, it just has to note |
| 387 | # that the breakpoint condition is false and keep going. |
| 388 | |
| 389 | gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = $void" \ |
| 390 | "p func1 () #1 in signals.exp" |
| 391 | |
| 392 | # Make sure the count got incremented. |
| 393 | |
| 394 | # Haven't investigated this xfail |
| 395 | setup_xfail "rs6000-*-*" |
| 396 | setup_xfail "powerpc-*-*" |
| 397 | gdb_test "p count" "= 2" "p count #1 in signals.exp" |
| 398 | if { [istarget "rs6000-*-*"] || [istarget "powerpc-*-*"] } { return 0 } |
| 399 | |
| 400 | gdb_test "condition \$handler_breakpoint_number" "now unconditional\\." |
| 401 | gdb_test "next" "alarm \\(.*" "next to alarm #2 in signals.exp" |
| 402 | gdb_test "next" "\\+\\+count; /\\* second \\*/" \ |
| 403 | "next to ++count #2 in signals.exp" |
| 404 | sleep 2 |
| 405 | |
| 406 | # This time we stop when GDB tries to run the stack dummy. |
| 407 | # So it is OK that we do not print the return value from the function. |
| 408 | gdb_test "p func1 ()" \ |
| 409 | "Breakpoint \[0-9\]*, handler.* |
| 410 | The program being debugged stopped while in a function called from GDB.*" \ |
| 411 | "p func1 () #2 in signals.exp" |
| 412 | # But we should be able to backtrace... |
| 413 | # On alpha-*-osf2.0 this test works when run manually but sometime fails when |
| 414 | # run under dejagnu, making it very hard to debug the problem. Weird... |
| 415 | gdb_test "bt 10" "#0.*handler.*#1.*#2.*main.*" "bt in signals.exp" |
| 416 | # ...and continue... |
| 417 | gdb_test "continue" "Continuing\\." "continue in signals.exp" |
| 418 | # ...and then count should have been incremented |
| 419 | gdb_test "p count" "= 5" "p count #2 in signals.exp" |
| 420 | |
| 421 | |
| 422 | # Verify that "info signals" produces reasonable output. |
| 423 | # |
| 424 | send_gdb "info signals\n" |
| 425 | gdb_expect { |
| 426 | -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 $"\ |
| 427 | {pass "info signals"} |
| 428 | -re "$gdb_prompt $"\ |
| 429 | {fail "info signals"} |
| 430 | timeout {fail "(timeout) info signals"} |
| 431 | } |
| 432 | |
| 433 | # Verify that "info signal" correctly handles an argument, be it a |
| 434 | # symbolic signal name, or an integer ID. |
| 435 | # |
| 436 | send_gdb "info signal SIGTRAP\n" |
| 437 | gdb_expect { |
| 438 | -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\ |
| 439 | {pass "info signal SIGTRAP"} |
| 440 | -re "$gdb_prompt $"\ |
| 441 | {fail "info signal SIGTRAP"} |
| 442 | timeout {fail "(timeout) info signal SIGTRAP"} |
| 443 | } |
| 444 | |
| 445 | send_gdb "info signal 5\n" |
| 446 | gdb_expect { |
| 447 | -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\ |
| 448 | {pass "info signal 5"} |
| 449 | -re "$gdb_prompt $"\ |
| 450 | {fail "info signal 5"} |
| 451 | timeout {fail "(timeout) info signal 5"} |
| 452 | } |
| 453 | |
| 454 | # Verify that "handle" with illegal arguments is gracefully, um, handled. |
| 455 | # |
| 456 | send_gdb "handle\n" |
| 457 | gdb_expect { |
| 458 | -re "Argument required .signal to handle.*$gdb_prompt $"\ |
| 459 | {pass "handle without arguments"} |
| 460 | -re "$gdb_prompt $"\ |
| 461 | {fail "handle without arguments"} |
| 462 | timeout {fail "(timeout) handle without arguments"} |
| 463 | } |
| 464 | |
| 465 | send_gdb "handle SIGFOO\n" |
| 466 | gdb_expect { |
| 467 | -re "Unrecognized or ambiguous flag word: \"SIGFOO\".*$gdb_prompt $"\ |
| 468 | {pass "handle with bogus SIG"} |
| 469 | -re "$gdb_prompt $"\ |
| 470 | {fail "handle with bogus SIG"} |
| 471 | timeout {fail "(timeout) handle with bogus SIG"} |
| 472 | } |
| 473 | |
| 474 | send_gdb "handle SIGHUP frump\n" |
| 475 | gdb_expect { |
| 476 | -re "Unrecognized or ambiguous flag word: \"frump\".*$gdb_prompt $"\ |
| 477 | {pass "handle SIG with bogus action"} |
| 478 | -re "$gdb_prompt $"\ |
| 479 | {fail "handle SIG with bogus action"} |
| 480 | timeout {fail "(timeout) handle SIG with bogus action"} |
| 481 | } |
| 482 | |
| 483 | # Verify that "handle" can take multiple actions per SIG, and that in |
| 484 | # the case of conflicting actions, that the rightmost action "wins". |
| 485 | # |
| 486 | send_gdb "handle SIGHUP print noprint\n" |
| 487 | gdb_expect { |
| 488 | -re ".*SIGHUP\[ \t\]*No\[ \t\]*No\[ \t\]*Yes\[ \t\]*Hangup.*$gdb_prompt $"\ |
| 489 | {pass "handle SIG with multiple conflicting actions"} |
| 490 | -re "$gdb_prompt $"\ |
| 491 | {fail "handle SIG with multiple conflicting actions"} |
| 492 | timeout {fail "(timeout) handle SIG with multiple conflicting actions"} |
| 493 | } |
| 494 | |
| 495 | # Exercise all the various actions. (We don't care what the outcome |
| 496 | # is, this is just to ensure that they all can be parsed.) |
| 497 | # |
| 498 | send_gdb "handle SIGHUP print noprint stop nostop ignore noignore pass nopass\n" |
| 499 | gdb_expect { |
| 500 | -re ".*Signal.*$gdb_prompt $"\ |
| 501 | {pass "handle SIG parses all legal actions"} |
| 502 | -re "$gdb_prompt $"\ |
| 503 | {fail "handle SIG parses all legal actions"} |
| 504 | timeout {fail "(timeout) handle SIG parses all legal actions"} |
| 505 | } |
| 506 | |
| 507 | # Verify that we can "handle" multiple signals at once, interspersed |
| 508 | # with actions. |
| 509 | # |
| 510 | send_gdb "handle SIG63 print SIGILL\n" |
| 511 | gdb_expect { |
| 512 | -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 $"\ |
| 513 | {pass "handle multiple SIGs"} |
| 514 | -re "$gdb_prompt $"\ |
| 515 | {fail "handle multiple SIGs"} |
| 516 | timeout {fail "(timeout) handle multiple SIGs"} |
| 517 | } |
| 518 | |
| 519 | # Verify that "handle" can take a numeric argument for the signal ID, |
| 520 | # rather than a symbolic name. (This may not be portable; works for |
| 521 | # HP-UX.) |
| 522 | # |
| 523 | # Also note that this testpoint overrides SIGTRAP, which on HP-UX at |
| 524 | # least, is used to implement single-steps and breakpoints. Don't |
| 525 | # expect to run the inferior after this! |
| 526 | # |
| 527 | send_gdb "handle 5 nopass\n" |
| 528 | gdb_expect { |
| 529 | -re ".*SIGTRAP is used by the debugger.*Are you sure you want to change it.*y or n.*"\ |
| 530 | {send_gdb "y\n" |
| 531 | gdb_expect { |
| 532 | -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\ |
| 533 | {pass "override SIGTRAP (#5)"} |
| 534 | -re "$gdb_prompt $"\ |
| 535 | {fail "override SIGTRAP (#5)"} |
| 536 | timeout {fail "(timeout) override SIGTRAP (#5)"} |
| 537 | } |
| 538 | } |
| 539 | -re "$gdb_prompt $"\ |
| 540 | {fail "override SIGTRAP (#5)"} |
| 541 | timeout {fail "(timeout) override SIGTRAP (#5)"} |
| 542 | } |
| 543 | |
| 544 | # GDB doesn't seem to allow numeric signal IDs larger than 15. Verify |
| 545 | # that restriction. ??rehrauer: Not sure if this is a feature or a |
| 546 | # bug, actually. Why is the range 1-15? |
| 547 | # |
| 548 | send_gdb "handle 58\n" |
| 549 | gdb_expect { |
| 550 | -re "Only signals 1-15 are valid as numeric signals.*Use \"info signals\" for a list of symbolic signals.*$gdb_prompt $"\ |
| 551 | {pass "invalid signal number rejected"} |
| 552 | -re "$gdb_prompt $"\ |
| 553 | {fail "invalid signal number rejected"} |
| 554 | timeout {fail "(timeout) invalid signal number rejected"} |
| 555 | } |
| 556 | |
| 557 | # Verify that we can accept a signal ID range (number-number). |
| 558 | # ??rehrauer: This feature isn't documented on the quick-reference |
| 559 | # card. |
| 560 | # |
| 561 | send_gdb "handle 13-15\n" |
| 562 | gdb_expect { |
| 563 | -re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $"\ |
| 564 | {pass "handle multiple SIGs via integer range"} |
| 565 | -re "$gdb_prompt $"\ |
| 566 | {fail "handle multiple SIGs via integer range"} |
| 567 | timeout {fail "(timeout) handle multiple SIGs via integer range"} |
| 568 | |
| 569 | } |
| 570 | |
| 571 | # Bizarrely enough, GDB also allows you to reverse the range |
| 572 | # stat, stop IDs. E.g., "3-1" and "1-3" mean the same thing. |
| 573 | # Probably this isn't documented, but the code anticipates it, |
| 574 | # so we'd best test it... |
| 575 | # |
| 576 | send_gdb "handle 15-13\n" |
| 577 | gdb_expect { |
| 578 | -re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $"\ |
| 579 | {pass "handle multiple SIGs via integer range"} |
| 580 | -re "$gdb_prompt $"\ |
| 581 | {fail "handle multiple SIGs via integer range"} |
| 582 | timeout {fail "(timeout) handle multiple SIGs via integer range"} |
| 583 | |
| 584 | } |
| 585 | |
| 586 | # SIGINT is used by the debugger as well. Verify that we can change |
| 587 | # our minds about changing it. |
| 588 | # |
| 589 | send_gdb "handle SIGINT nopass\n" |
| 590 | gdb_expect { |
| 591 | -re ".*SIGINT is used by the debugger.*Are you sure you want to change it.*y or n.*"\ |
| 592 | {send_gdb "n\n" |
| 593 | # ??rehrauer: When you answer "n", the header for the signal info is |
| 594 | # printed, but not the actual handler settings. Probably a bug. |
| 595 | # |
| 596 | gdb_expect { |
| 597 | -re "Not confirmed, unchanged.*Signal.*$gdb_prompt $"\ |
| 598 | {pass "override SIGINT"} |
| 599 | -re "$gdb_prompt $"\ |
| 600 | {fail "override SIGINT"} |
| 601 | timeout {fail "(timeout) override SIGINT"} |
| 602 | } |
| 603 | } |
| 604 | -re "$gdb_prompt $"\ |
| 605 | {fail "override SIGINT"} |
| 606 | timeout {fail "(timeout) override SIGINT"} |
| 607 | } |
| 608 | |
| 609 | # Verify that GDB responds gracefully to the "signal" command with |
| 610 | # a missing argument. |
| 611 | # |
| 612 | send_gdb "signal\n" |
| 613 | gdb_expect { |
| 614 | -re "Argument required .signal number..*$gdb_prompt $"\ |
| 615 | {pass "signal without arguments disallowed"} |
| 616 | -re "$gdb_prompt $"\ |
| 617 | {fail "signal without arguments disallowed"} |
| 618 | timeout {fail "(timeout) signal without arguments disallowed"} |
| 619 | } |
| 620 | |
| 621 | # Verify that we can successfully send a signal other than 0 to |
| 622 | # the inferior. (This probably causes the inferior to run away. |
| 623 | # Be prepared to rerun to main for further testing.) |
| 624 | # |
| 625 | send_gdb "signal 5\n" |
| 626 | gdb_expect { |
| 627 | -re "Continuing with signal SIGTRAP.*$gdb_prompt $"\ |
| 628 | {pass "sent signal 5"} |
| 629 | -re "$gdb_prompt $"\ |
| 630 | {fail "sent signal 5"} |
| 631 | timeout {fail "(timeout) sent signal 5"} |
| 632 | } |
| 633 | |
| 634 | } |
| 635 | |
| 636 | return 0 |