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