8 set binfile $objdir/$subdir/signals
10 if ![file exists $binfile] then {
11 perror "$binfile does not exist."
15 proc signal_tests_1 {} {
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 \\*/" \
24 # An alarm has been signaled, give the signal time to get delivered.
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*"
36 -re "alarm .*$prompt $" { pass "next to 2nd alarm (1)" }
37 -re "Program received signal SIGTRAP.*first.*$prompt $" {
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
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.
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.
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
64 fail "next to 2nd alarm (1) (probably kernel bug)"
65 gdb_test "next" "alarm.*" "next to 2nd alarm (1)"
67 -re "Program exited with code.*$prompt $" {
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.
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.
84 fail "'next' behaved as 'continue'"
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)" }
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.
101 -re "Breakpoint.*handler.*$prompt $" {
102 pass "next to handler in signals_tests_1"
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)"
109 gdb_test "signal 0" "Breakpoint.*handler.*"
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)" }
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"
122 gdb_test "break func1" "Breakpoint \[0-9\]+ .*"
123 gdb_test "break func2" "Breakpoint \[0-9\]+ .*"
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*"
131 -re "Breakpoint.*func1.*$prompt $" { pass "continue to func1" }
132 -re "Program received signal SIGTRAP.*second.*$prompt $" {
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.
140 fail "continue to func1 (probably kernel bug)"
141 gdb_test "continue" "Breakpoint.*func1.*" \
142 "extra continue to func1"
144 -re "Program received signal SIGTRAP.*func1 ..;.*$prompt $" {
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.
150 fail "continue to func1 (probably kernel bug)"
151 gdb_test "continue" "Breakpoint.*func1.*" \
152 "extra continue to func1"
154 -re ".*$prompt $" { fail "continue to func1" }
155 default { fail "continue to func1" }
158 setup_xfail "*-*-irix*"
159 send "signal SIGUSR1\n"
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"
168 -re ".*$prompt $" { fail "signal SIGUSR1" }
169 default { fail "signal SIGUSR1" }
172 # Will tend to wrongly require an extra continue.
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
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"
192 -re ".*$prompt $" { fail "continue to func2" }
193 default { fail "continue to func2" }
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.
205 setup_xfail "sparc-*-*"
206 setup_xfail "rs6000-*-*"
208 # A faulty bash will not step the inferior into sigtramp on sun3.
209 if {$bash_bug} then {
210 setup_xfail "m68*-*-sunos4*"
213 gdb_test "continue" "Breakpoint.*handler.*" "continue to handler"
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.
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*"
225 gdb_test "continue" "Program exited with code 010\\." \
226 "continue to exit in signals_tests_1 "
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
240 if {[ istarget "m68*-motorola-*" ] || [ istarget "hppa*-*-bsd*" ] ||
241 [ istarget "*-*-hpux*" ] || [ istarget "hppa*-*-osf*" ]} then {
243 fail "ptrace loses on signals on this target"
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"
257 gdb_reinitialize_dir $srcdir/$subdir
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).
265 -re "= 2.*$prompt $" {}
266 -re ".*$prompt $" { perror "sync trouble in signals.exp" }
267 default { perror "sync trouble in signals.exp" }
270 if [runto_main] then {
271 gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*"
272 gdb_test "set \$handler_breakpoint_number = \$bpnum" ""
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
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.
287 gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = void" \
288 "p func1 () #1 in signals.exp"
290 # Make sure the count got incremented.
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 }
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"
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"
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"