Commit | Line | Data |
---|---|---|
98f6da4f C |
1 | if $tracelevel then { |
2 | strace $tracelevel | |
3 | } | |
4 | ||
5 | set prms_id 0 | |
6 | set bug_id 0 | |
7 | ||
98f6da4f C |
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 { | |
4081daa1 JK |
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 \\*/" \ | |
98f6da4f C |
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)" | |
4081daa1 | 65 | gdb_test "next" "alarm.*" "next to 2nd alarm (1)" |
98f6da4f C |
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 | ||
4081daa1 JK |
92 | gdb_test "break handler" "Breakpoint \[0-9\]+ .*" |
93 | gdb_test "next" "\\+\\+count; /\\* second \\*/" \ | |
94 | "next to 2nd ++count in signals_tests_1" | |
98f6da4f C |
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 { | |
4081daa1 JK |
101 | -re "Breakpoint.*handler.*$prompt $" { |
102 | pass "next to handler in signals_tests_1" | |
103 | } | |
98f6da4f C |
104 | -re "Program received signal SIGEMT.*$prompt $" { |
105 | # Bash versions before 1.13.5 cause this behaviour | |
106 | # by blocking SIGTRAP. | |
4081daa1 | 107 | fail "next to handler in signals_tests_1 (known problem with bash versions before 1.13.5)" |
98f6da4f | 108 | set bash_bug 1 |
4081daa1 | 109 | gdb_test "signal 0" "Breakpoint.*handler.*" |
98f6da4f | 110 | } |
4081daa1 JK |
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)" } | |
98f6da4f C |
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). | |
4081daa1 JK |
119 | gdb_test "backtrace" "#0.*handler.*#1.*#2.*main.*" \ |
120 | "backtrace in signals_tests_1" | |
98f6da4f | 121 | |
4081daa1 JK |
122 | gdb_test "break func1" "Breakpoint \[0-9\]+ .*" |
123 | gdb_test "break func2" "Breakpoint \[0-9\]+ .*" | |
98f6da4f C |
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 { | |
4081daa1 | 131 | -re "Breakpoint.*func1.*$prompt $" { pass "continue to func1" } |
98f6da4f C |
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 | ||
4081daa1 JK |
140 | fail "continue to func1 (probably kernel bug)" |
141 | gdb_test "continue" "Breakpoint.*func1.*" \ | |
142 | "extra continue to func1" | |
98f6da4f C |
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 | ||
4081daa1 JK |
150 | fail "continue to func1 (probably kernel bug)" |
151 | gdb_test "continue" "Breakpoint.*func1.*" \ | |
152 | "extra continue to func1" | |
98f6da4f | 153 | } |
4081daa1 JK |
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" } | |
98f6da4f | 170 | } |
98f6da4f C |
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 { | |
4081daa1 | 186 | -re "Breakpoint.*func2.*$prompt $" { pass "continue to func2" } |
98f6da4f | 187 | -re "Breakpoint.*func1.*$prompt $" { |
0926990e | 188 | fail "continue to func2" |
4081daa1 JK |
189 | gdb_test "continue" "Breakpoint.*func2.*" \ |
190 | "extra continue to func2" | |
98f6da4f | 191 | } |
4081daa1 JK |
192 | -re ".*$prompt $" { fail "continue to func2" } |
193 | default { fail "continue to func2" } | |
98f6da4f C |
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 | ||
4081daa1 | 213 | gdb_test "continue" "Breakpoint.*handler.*" "continue to handler" |
98f6da4f C |
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 | } | |
4081daa1 JK |
225 | gdb_test "continue" "Program exited with code 010\\." \ |
226 | "continue to exit in signals_tests_1 " | |
98f6da4f C |
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 | ||
0926990e JK |
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 | ||
6535b97b JK |
255 | gdb_exit |
256 | gdb_start | |
4081daa1 | 257 | gdb_reinitialize_dir $srcdir/$subdir |
6535b97b JK |
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 | } | |
98f6da4f | 269 | |
6535b97b | 270 | if [runto main] then { |
4081daa1 | 271 | gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*" |
6535b97b | 272 | gdb_test "set \$handler_breakpoint_number = \$bpnum" "" |
98f6da4f | 273 | |
6535b97b | 274 | # Get to the point where a signal is waiting to be delivered |
4081daa1 JK |
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" | |
6535b97b JK |
279 | # Give the signal time to get delivered |
280 | exec sleep 2 | |
98f6da4f | 281 | |
6535b97b JK |
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. | |
98f6da4f | 286 | |
4081daa1 JK |
287 | gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = void" \ |
288 | "p func1 () #1 in signals.exp" | |
98f6da4f | 289 | |
6535b97b | 290 | # Make sure the count got incremented. |
98f6da4f | 291 | |
6535b97b JK |
292 | # Haven't investigated this xfail |
293 | setup_xfail "rs6000-*-*" | |
4081daa1 | 294 | gdb_test "p count" "= 2" "p count #1 in signals.exp" |
6535b97b JK |
295 | if [istarget "rs6000-*-*"] { return 0 } |
296 | ||
4081daa1 JK |
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" | |
6535b97b | 301 | exec sleep 2 |
98f6da4f | 302 | |
6535b97b JK |
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 ()" \ | |
98f6da4f | 306 | "Breakpoint \[0-9\]*, handler.* |
4081daa1 JK |
307 | The program being debugged stopped while in a function called from GDB.*" \ |
308 | "p func1 () #2 in signals.exp" | |
6535b97b | 309 | # But we should be able to backtrace... |
4081daa1 | 310 | gdb_test "bt" "#0.*handler.*#1.*#2.*main.*" "bt in signals.exp" |
6535b97b | 311 | # ...and continue... |
4081daa1 | 312 | gdb_test "continue" "Continuing\\." "continue in signals.exp" |
6535b97b | 313 | # ...and then count should have been incremented |
4081daa1 | 314 | gdb_test "p count" "= 5" "p count #2 in signals.exp" |
98f6da4f | 315 | } |
6535b97b | 316 | |
98f6da4f | 317 | return 0 |