gdb/testsuite/gdb.base/signals.exp

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