gdb/testsuite/gdb.base/signals.exp

   1 if $tracelevel then {
   2         strace $tracelevel
   3 }
   4
   5 set prms_id 0
   6 set bug_id 0
   7
   8 set binfile $objdir/$subdir/signals
   9
  10 if ![file exists $binfile] then {
  11     perror "$binfile does not exist."
  12     return 0
  13 }
  14
  15 proc signal_tests_1 {} {
  16     global prompt
  17     if [runto main] then {
  18         gdb_test "next" "signal \\(SIGUSR1.*" \
  19                 "next over signal (SIGALRM, handler)"
  20         gdb_test "next" "alarm \\(.*" \
  21                 "next over signal (SIGUSR1, handler)"
  22         gdb_test "next" "\\+\\+count; /\\* first \\*/" \
  23                 "next over alarm (1)"
  24         # An alarm has been signaled, give the signal time to get delivered.
  25         exec sleep 2
  26
  27         # i386 BSD currently fails the next test with a SIGTRAP.
  28         setup_xfail "i*86-*-bsd*"
  29         # But Dynix has a DECR_PC_AFTER_BREAK of zero, so the failure
  30         # is shadowed by hitting the through_sigtramp_breakpoint.
  31         clear_xfail "i*86-sequent-bsd*"
  32         # Univel SVR4 i386 continues instead of stepping.
  33         setup_xfail "i*86-univel-sysv4*"
  34         send "next\n"
  35         expect {
  36             -re "alarm .*$prompt $" { pass "next to 2nd alarm (1)" }
  37             -re "Program received signal SIGTRAP.*first.*$prompt $" {
  38
  39                 # This can happen on machines that have a trace flag
  40                 # in their PS register.
  41                 # The trace flag in the PS register will be set due to
  42                 # the `next' command.
  43                 # Before calling the signal handler, the PS register
  44                 # is pushed along with the context on the user stack.
  45                 # When the signal handler has finished, it reenters the
  46                 # the kernel via a sigreturn syscall, which restores the
  47                 # PS register along with the context.
  48                 # If the kernel erroneously does not clear the trace flag
  49                 # in the pushed context, gdb will receive a SIGTRAP from
  50                 # the set trace flag in the restored context after the
  51                 # signal handler has finished.
  52
  53                 # I do not yet understand why the SIGTRAP does not occur
  54                 # after stepping the instruction at the restored PC on
  55                 # i386 BSDI 1.0 systems.
  56
  57                 # Note that the vax under Ultrix also exhibits
  58                 # this behaviour (it is uncovered by the `continue from
  59                 # a break in a signal handler' test below).
  60                 # With this test the failure is shadowed by hitting the
  61                 # through_sigtramp_breakpoint upon return from the signal
  62                 # handler.
  63
  64                 fail "next to 2nd alarm (1) (probably kernel bug)"
  65                 gdb_test "next" "alarm.*" "next to 2nd alarm (1)"
  66             }
  67             -re "Program exited with code.*$prompt $" {
  68
  69                 # This is apparently a bug in the UnixWare kernel (but
  70                 # has not been investigated beyond the
  71                 # resume/target_wait level, and has not been reported
  72                 # to Univel).  If it steps when a signal is pending,
  73                 # it does a continue instead.  I don't know whether
  74                 # there is a workaround.
  75
  76                 # Perhaps this problem exists on other SVR4 systems;
  77                 # but (a) we have no reason to think so, and (b) if we
  78                 # put a wrong xfail here, we never get an XPASS to let
  79                 # us know that it was incorrect (and then if such a
  80                 # configuration regresses we have no way of knowing).
  81                 # Solaris is not a relevant data point either way
  82                 # because it lacks single stepping.
  83
  84                 fail "'next' behaved as 'continue'"
  85                 return 0
  86             }
  87             -re ".*$prompt $" { fail "next to 2nd alarm (1)" }
  88             timeout { fail "next to 2nd alarm (1); (timeout)" }
  89             eof { fail "next to 2nd alarm (1); (eof)" }
  90         }
  91
  92         gdb_test "break handler" "Breakpoint \[0-9\]+ .*"
  93         gdb_test "next" "\\+\\+count; /\\* second \\*/" \
  94             "next to 2nd ++count in signals_tests_1"
  95         # An alarm has been signaled, give the signal time to get delivered.
  96         exec sleep 2
  97
  98         set bash_bug 0
  99         send "next\n"
 100         expect {
 101             -re "Breakpoint.*handler.*$prompt $" {
 102                 pass "next to handler in signals_tests_1"
 103             }
 104             -re "Program received signal SIGEMT.*$prompt $" {
 105                 # Bash versions before 1.13.5 cause this behaviour
 106                 # by blocking SIGTRAP.
 107                 fail "next to handler in signals_tests_1 (known problem with bash versions before 1.13.5)"
 108                 set bash_bug 1
 109                 gdb_test "signal 0" "Breakpoint.*handler.*"
 110             }
 111             -re ".*$prompt $" { fail "next to handler in signals_tests_1" }
 112             timeout { fail "next to handler in signals_tests_1 (timeout)" }
 113             eof { fail "next to handler in signals_tests_1 (eof)" }
 114         }
 115
 116         # This doesn't test that main is frame #2, just that main is frame
 117         # #2, #3, or higher.  At some point this should be fixed (but
 118         # it quite possibly would introduce new FAILs on some systems).
 119         gdb_test "backtrace" "#0.*handler.*#1.*#2.*main.*" \
 120             "backtrace in signals_tests_1"
 121
 122         gdb_test "break func1" "Breakpoint \[0-9\]+ .*"
 123         gdb_test "break func2" "Breakpoint \[0-9\]+ .*"
 124
 125         # Vax Ultrix and i386 BSD currently fail the next test with
 126         # a SIGTRAP, but with different symptoms.
 127         setup_xfail "vax-*-ultrix*"
 128         setup_xfail "i*86-*-bsd*"
 129         send "continue\n"
 130         expect {
 131             -re "Breakpoint.*func1.*$prompt $" { pass "continue to func1" }
 132             -re "Program received signal SIGTRAP.*second.*$prompt $" {
 133
 134                 # See explanation for `next to 2nd alarm (1)' fail above.
 135                 # We did step into the signal handler, hit a breakpoint
 136                 # in the handler and continued from the breakpoint.
 137                 # The set trace flag in the restored context is causing
 138                 # the SIGTRAP, without stepping an instruction.
 139
 140                 fail "continue to func1 (probably kernel bug)"
 141                 gdb_test "continue" "Breakpoint.*func1.*" \
 142                     "extra continue to func1"
 143             }
 144             -re "Program received signal SIGTRAP.*func1 ..;.*$prompt $" {
 145
 146                 # On the vax under Ultrix the set trace flag in the restored
 147                 # context is causing the SIGTRAP, but after stepping one
 148                 # instruction, as expected.
 149
 150                 fail "continue to func1 (probably kernel bug)"
 151                 gdb_test "continue" "Breakpoint.*func1.*" \
 152                     "extra continue to func1"
 153             }
 154             -re ".*$prompt $" { fail "continue to func1" }
 155             default { fail "continue to func1" }
 156         }
 157
 158         setup_xfail "*-*-irix*"
 159         send "signal SIGUSR1\n"
 160         expect {
 161             -re "Breakpoint.*handler.*$prompt $" { pass "signal SIGUSR1" }
 162             -re "Program received signal SIGUSR1.*$prompt $" {
 163                 # This is what irix4 and irix5 do.
 164                 # It would appear to be a kernel bug.
 165                 fail "signal SIGUSR1"
 166                 gdb_test "continue" "Breakpoint.*handler.*" "pass it SIGUSR1"
 167             }
 168             -re ".*$prompt $" { fail "signal SIGUSR1" }
 169             default { fail "signal SIGUSR1" }
 170         }
 171
 172         # Will tend to wrongly require an extra continue.
 173
 174         # The problem here is that the breakpoint at func1 will be
 175         # inserted, and when the system finishes with the signal
 176         # handler it will try to execute there.  For GDB to try to
 177         # remember that it was going to step over a breakpoint when a
 178         # signal happened, distinguish this case from the case where
 179         # func1 is called from the signal handler, etc., seems
 180         # exceedingly difficult.  So don't expect this to get fixed
 181         # anytime soon.
 182
 183         setup_xfail "*-*-*"
 184         send "continue\n"
 185         expect {
 186             -re "Breakpoint.*func2.*$prompt $" { pass "continue to func2" }
 187             -re "Breakpoint.*func1.*$prompt $" {
 188                 fail "continue to func2"
 189                 gdb_test "continue" "Breakpoint.*func2.*" \
 190                     "extra continue to func2"
 191             }
 192             -re ".*$prompt $" { fail "continue to func2" }
 193             default { fail "continue to func2" }
 194         }
 195
 196         exec sleep 2
 197
 198         # GDB yanks out the breakpoints to step over the breakpoint it
 199         # stopped at, which means the breakpoint at handler is yanked.
 200         # But if NO_SINGLE_STEP, we won't get another chance to reinsert
 201         # them (at least not with procfs, where we tell the kernel not
 202         # to tell gdb about `pass' signals).  So the fix would appear to
 203         # be to just yank that one breakpoint when we step over it.
 204
 205         setup_xfail "sparc-*-*"
 206         setup_xfail "rs6000-*-*"
 207
 208         # A faulty bash will not step the inferior into sigtramp on sun3.
 209         if {$bash_bug} then {
 210             setup_xfail "m68*-*-sunos4*"
 211         }
 212
 213         gdb_test "continue" "Breakpoint.*handler.*" "continue to handler"
 214
 215         # If the NO_SINGLE_STEP failure happened, we have already exited.
 216         # If we succeeded a continue will return from the handler to func2.
 217         # GDB now has `forgotten' that it intended to step over the
 218         # breakpoint at func2 and will stop at func2.
 219         setup_xfail "*-*-*"
 220         # The sun3 with a faulty bash will also be `forgetful' but it
 221         # already got the spurious stop at func2 and this continue will work.
 222         if {$bash_bug} then {
 223              clear_xfail "m68*-*-sunos4*"
 224         }
 225         gdb_test "continue" "Program exited with code 010\\." \
 226             "continue to exit in signals_tests_1 "
 227     }
 228 }
 229
 230 # On a few losing systems, ptrace (PT_CONTINUE) or ptrace (PT_STEP)
 231 # causes pending signals to be cleared, which causes these tests to
 232 # get nowhere fast.  This is totally losing behavior (perhaps there
 233 # are cases in which is it useful but the user needs more control,
 234 # which they mostly have in GDB), but some people apparently think it
 235 # is a feature.  It is documented in the ptrace manpage on Motorola
 236 # Delta Series sysV68 R3V7.1 and on HPUX 9.0.  Even the non-HPUX PA
 237 # OSes (BSD and OSF/1) seem to have figured they had to copy this
 238 # braindamage.
 239
 240 if {[ istarget "m68*-motorola-*" ] || [ istarget "hppa*-*-bsd*" ] ||
 241     [ istarget "*-*-hpux*" ] || [ istarget "hppa*-*-osf*" ]} then {
 242   setup_xfail "*-*-*"
 243   fail "ptrace loses on signals on this target"
 244   return 0
 245 }
 246
 247 gdb_exit
 248 gdb_start
 249
 250 # This will need to be updated as the exact list of signals changes,
 251 # but I want to test that TARGET_SIGNAL_0, TARGET_SIGNAL_DEFAULT, and
 252 # TARGET_SIGNAL_UNKNOWN are skipped.
 253 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"
 254
 255 gdb_exit
 256 gdb_start
 257 gdb_reinitialize_dir $srcdir/$subdir
 258 gdb_load $binfile
 259 signal_tests_1
 260
 261 # Force a resync, so we're looking at the right prompt.  On SCO we
 262 # were getting out of sync (I don't understand why).
 263 send "p 1+1\n"
 264 expect {
 265     -re "= 2.*$prompt $" {}
 266     -re ".*$prompt $" { perror "sync trouble in signals.exp" }
 267     default { perror "sync trouble in signals.exp" }
 268 }
 269
 270 if [runto main] then {
 271     gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*"
 272     gdb_test "set \$handler_breakpoint_number = \$bpnum" ""
 273
 274     # Get to the point where a signal is waiting to be delivered
 275     gdb_test "next" "signal \\(SIGUSR1.*" "next to signal in signals.exp"
 276     gdb_test "next" "alarm \\(.*" "next to alarm #1 in signals.exp"
 277     gdb_test "next" "\\+\\+count; /\\* first \\*/" \
 278         "next to ++count #1 in signals.exp"
 279     # Give the signal time to get delivered
 280     exec sleep 2
 281
 282     # Now call a function.  When GDB tries to run the stack dummy,
 283     # it will hit the breakpoint at handler.  Provided it doesn't
 284     # lose its cool, this is not a problem, it just has to note
 285     # that the breakpoint condition is false and keep going.
 286
 287     gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = void" \
 288         "p func1 () #1 in signals.exp"
 289
 290     # Make sure the count got incremented.
 291
 292     # Haven't investigated this xfail
 293     setup_xfail "rs6000-*-*"
 294     gdb_test "p count" "= 2" "p count #1 in signals.exp"
 295     if [istarget "rs6000-*-*"] { return 0 }
 296
 297     gdb_test "condition \$handler_breakpoint_number" "now unconditional\\."
 298     gdb_test "next" "alarm \\(.*" "next to alarm #2 in signals.exp"
 299     gdb_test "next" "\\+\\+count; /\\* second \\*/" \
 300         "next to ++count #2 in signals.exp"
 301     exec sleep 2
 302
 303     # This time we stop when GDB tries to run the stack dummy.
 304     # So it is OK that we do not print the return value from the function.
 305     gdb_test "p func1 ()" \
 306 "Breakpoint \[0-9\]*, handler.*
 307 The program being debugged stopped while in a function called from GDB.*" \
 308         "p func1 () #2 in signals.exp"
 309     # But we should be able to backtrace...
 310     gdb_test "bt" "#0.*handler.*#1.*#2.*main.*" "bt in signals.exp"
 311     # ...and continue...
 312     gdb_test "continue" "Continuing\\." "continue in signals.exp"
 313     # ...and then count should have been incremented
 314     gdb_test "p count" "= 5" "p count #2 in signals.exp"
 315 }
 316
 317 return 0