gdb/testsuite/gdb.base/signals.exp

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