Commit | Line | Data |
---|---|---|
78650829 | 1 | # Copyright 1997, 1998, 1999, 2003, 2004 Free Software Foundation, Inc. |
c906108c SS |
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 | ||
c906108c SS |
17 | if [target_info exists gdb,nosignals] { |
18 | verbose "Skipping signals.exp because of nosignals." | |
19 | continue | |
20 | } | |
21 | ||
22 | if $tracelevel then { | |
23 | strace $tracelevel | |
24 | } | |
25 | ||
26 | set prms_id 0 | |
27 | set bug_id 0 | |
28 | ||
29 | set testfile signals | |
30 | set srcfile ${testfile}.c | |
31 | set binfile ${objdir}/${subdir}/${testfile} | |
32 | if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } { | |
78650829 | 33 | gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." |
c906108c SS |
34 | } |
35 | ||
36 | # Create and source the file that provides information about the compiler | |
37 | # used to compile the test case. | |
38 | if [get_compiler_info ${binfile}] { | |
39 | return -1; | |
40 | } | |
41 | ||
085dd6e6 JM |
42 | if {$hp_cc_compiler} { |
43 | set void 0 | |
44 | } else { | |
45 | set void void | |
46 | } | |
47 | ||
c906108c SS |
48 | proc signal_tests_1 {} { |
49 | global gdb_prompt | |
50 | if [runto_main] then { | |
51 | gdb_test "next" "signal \\(SIGUSR1.*" \ | |
78650829 | 52 | "next over signal (SIGALRM, handler)" |
c906108c | 53 | gdb_test "next" "alarm \\(.*" \ |
78650829 | 54 | "next over signal (SIGUSR1, handler)" |
c906108c | 55 | gdb_test "next" "\\+\\+count; /\\* first \\*/" \ |
78650829 | 56 | "next over alarm (1)" |
c906108c SS |
57 | # An alarm has been signaled, give the signal time to get delivered. |
58 | sleep 2 | |
59 | ||
d303a6c7 AC |
60 | # NOTE: cagney/2004-05-09: The following is retained as an |
61 | # historical reference. Because signal delivery when doing a | |
62 | # next has been changed to use a continue, and not a | |
63 | # single-step, the kernel bug of a stuck trace-bit in the | |
64 | # trampoline's saved PS register is avoided. | |
65 | ||
66 | # This can happen on machines that have a trace flag in their | |
67 | # PS register. The trace flag in the PS register will be set | |
68 | # due to the `next' command. Before calling the signal | |
69 | # handler, the PS register is pushed along with the context on | |
70 | # the user stack. When the signal handler has finished, it | |
71 | # reenters the the kernel via a sigreturn syscall, which | |
72 | # restores the PS register along with the context. If the | |
73 | # kernel erroneously does not clear the trace flag in the | |
74 | # pushed context, gdb will receive a SIGTRAP from the set | |
75 | # trace flag in the restored context after the signal handler | |
76 | # has finished. | |
77 | ||
78 | # I do not yet understand why the SIGTRAP does not occur after | |
79 | # stepping the instruction at the restored PC on i386 BSDI 1.0 | |
80 | # systems. | |
81 | ||
82 | # Note that the vax under Ultrix also exhibits this behaviour | |
83 | # (it is uncovered by the `continue from a break in a signal | |
84 | # handler' test below). With this test the failure is | |
85 | # shadowed by hitting the through_sigtramp_breakpoint upon | |
86 | # return from the signal handler. | |
87 | ||
88 | # SVR4 and Linux based i*86 systems exhibit this behaviour as | |
89 | # well (it is uncovered by the `continue from a break in a | |
90 | # signal handler' test below). As these systems use procfs, | |
91 | # where we tell the kernel not to tell gdb about `pass' | |
92 | # signals, and the trace flag is cleared by the kernel before | |
93 | # entering the sigtramp routine, GDB will not notice the | |
94 | # execution of the signal handler. Upon return from the | |
95 | # signal handler, GDB will receive a SIGTRAP from the set | |
96 | # trace flag in the restored context. The SIGTRAP marks the | |
97 | # end of a (albeit long winded) single step for GDB, causing | |
98 | # this test to pass. | |
99 | ||
100 | gdb_test "next" "alarm .*" "next to 2nd alarm" | |
c906108c SS |
101 | |
102 | gdb_test "break handler" "Breakpoint \[0-9\]+ .*" | |
103 | gdb_test "next" "\\+\\+count; /\\* second \\*/" \ | |
104 | "next to 2nd ++count in signals_tests_1" | |
78650829 AC |
105 | |
106 | # An alarm has been signaled, give the signal time to get | |
107 | # delivered. | |
108 | ||
c906108c SS |
109 | sleep 2 |
110 | ||
111 | set bash_bug 0 | |
112 | send_gdb "next\n" | |
113 | gdb_expect { | |
114 | -re "Breakpoint.*handler.*$gdb_prompt $" { | |
115 | pass "next to handler in signals_tests_1" | |
116 | } | |
117 | -re "Program received signal SIGEMT.*$gdb_prompt $" { | |
78650829 AC |
118 | # Bash versions before 1.13.5 cause this behaviour by |
119 | # blocking SIGTRAP. | |
c906108c SS |
120 | fail "next to handler in signals_tests_1 (known problem with bash versions before 1.13.5)" |
121 | set bash_bug 1 | |
122 | gdb_test "signal 0" "Breakpoint.*handler.*" | |
123 | } | |
78650829 AC |
124 | -re ".*$gdb_prompt $" { |
125 | fail "next to handler in signals_tests_1" | |
126 | } | |
127 | timeout { | |
128 | fail "next to handler in signals_tests_1 (timeout)" | |
129 | } | |
130 | eof { | |
131 | fail "next to handler in signals_tests_1 (eof)" | |
132 | } | |
c906108c SS |
133 | } |
134 | ||
78650829 AC |
135 | # This doesn't test that main is frame #2, just that main is |
136 | # frame #2, #3, or higher. At some point this should be fixed | |
137 | # (but it quite possibly would introduce new FAILs on some | |
138 | # systems). | |
139 | ||
a0b3c4fd | 140 | setup_xfail "i*86-*-bsdi2.0" |
bea71854 | 141 | gdb_test "backtrace 10" "#0.*handler.*#1.*signal handler.*#2.* main .*" \ |
c906108c SS |
142 | "backtrace in signals_tests_1" |
143 | ||
144 | gdb_test "break func1" "Breakpoint \[0-9\]+ .*" | |
145 | gdb_test "break func2" "Breakpoint \[0-9\]+ .*" | |
146 | ||
d303a6c7 AC |
147 | # NOTE: cagney/2004-05-09: Ref "next to 2nd alarm" above. |
148 | # Because signal delivery when doing a next has been changed | |
149 | # to use a continue, and not a single-step, the kernel bug of | |
150 | # a stuck trace-bit in the trampoline's saved PS register is | |
151 | # avoided. | |
c906108c | 152 | |
d303a6c7 | 153 | gdb_test "continue" "Breakpoint.*func1.*" "continue to func1" |
c906108c SS |
154 | |
155 | setup_xfail "*-*-irix*" | |
156 | send_gdb "signal SIGUSR1\n" | |
157 | gdb_expect { | |
78650829 AC |
158 | -re "Breakpoint.*handler.*$gdb_prompt $" { |
159 | pass "signal SIGUSR1" | |
160 | } | |
c906108c SS |
161 | -re "Program received signal SIGUSR1.*$gdb_prompt $" { |
162 | # This is what irix4 and irix5 do. | |
163 | # It would appear to be a kernel bug. | |
164 | fail "signal SIGUSR1" | |
165 | gdb_test "continue" "Breakpoint.*handler.*" "pass it SIGUSR1" | |
166 | } | |
78650829 AC |
167 | -re ".*$gdb_prompt $" { |
168 | fail "signal SIGUSR1" | |
169 | } | |
170 | default { | |
171 | fail "signal SIGUSR1" | |
172 | } | |
c906108c SS |
173 | } |
174 | ||
175 | # Will tend to wrongly require an extra continue. | |
176 | ||
177 | # The problem here is that the breakpoint at func1 will be | |
178 | # inserted, and when the system finishes with the signal | |
179 | # handler it will try to execute there. For GDB to try to | |
180 | # remember that it was going to step over a breakpoint when a | |
181 | # signal happened, distinguish this case from the case where | |
182 | # func1 is called from the signal handler, etc., seems | |
183 | # exceedingly difficult. So don't expect this to get fixed | |
184 | # anytime soon. | |
185 | ||
186 | setup_xfail "*-*-*" | |
187 | send_gdb "continue\n" | |
188 | gdb_expect { | |
78650829 AC |
189 | -re "Breakpoint.*func2.*$gdb_prompt $" { |
190 | pass "continue to func2" | |
191 | } | |
c906108c SS |
192 | -re "Breakpoint.*func1.*$gdb_prompt $" { |
193 | fail "continue to func2" | |
194 | gdb_test "continue" "Breakpoint.*func2.*" \ | |
195 | "extra continue to func2" | |
196 | } | |
78650829 AC |
197 | -re ".*$gdb_prompt $" { |
198 | fail "continue to func2" | |
199 | } | |
200 | default { | |
201 | fail "continue to func2" | |
202 | } | |
c906108c SS |
203 | } |
204 | ||
205 | sleep 2 | |
206 | ||
207 | # GDB yanks out the breakpoints to step over the breakpoint it | |
208 | # stopped at, which means the breakpoint at handler is yanked. | |
78650829 AC |
209 | # But if SOFTWARE_SINGLE_STEP_P, we won't get another chance |
210 | # to reinsert them (at least not with procfs, where we tell | |
211 | # the kernel not to tell gdb about `pass' signals). So the | |
212 | # fix would appear to be to just yank that one breakpoint when | |
213 | # we step over it. | |
c906108c SS |
214 | |
215 | setup_xfail "sparc*-*-*" | |
216 | setup_xfail "rs6000-*-*" | |
217 | setup_xfail "powerpc-*-*" | |
218 | ||
219 | # A faulty bash will not step the inferior into sigtramp on sun3. | |
220 | if {$bash_bug} then { | |
221 | setup_xfail "m68*-*-sunos4*" | |
222 | } | |
78650829 | 223 | |
c906108c SS |
224 | setup_xfail "i*86-pc-linux-gnu*" |
225 | setup_xfail "i*86-*-solaris2*" | |
226 | gdb_test "continue" "Breakpoint.*handler.*" "continue to handler" | |
227 | ||
78650829 AC |
228 | # If the SOFTWARE_SINGLE_STEP_P failure happened, we have |
229 | # already exited. If we succeeded a continue will return from | |
230 | # the handler to func2. GDB now has `forgotten' that it | |
231 | # intended to step over the breakpoint at func2 and will stop | |
232 | # at func2. | |
233 | ||
c906108c | 234 | setup_xfail "*-*-*" |
78650829 | 235 | |
c906108c | 236 | # The sun3 with a faulty bash will also be `forgetful' but it |
78650829 AC |
237 | # already got the spurious stop at func2 and this continue |
238 | # will work. | |
239 | ||
c906108c SS |
240 | if {$bash_bug} then { |
241 | clear_xfail "m68*-*-sunos4*" | |
242 | } | |
243 | gdb_test "continue" "Program exited with code 010\\." \ | |
244 | "continue to exit in signals_tests_1 " | |
245 | } | |
246 | } | |
247 | ||
248 | # On a few losing systems, ptrace (PT_CONTINUE) or ptrace (PT_STEP) | |
249 | # causes pending signals to be cleared, which causes these tests to | |
250 | # get nowhere fast. This is totally losing behavior (perhaps there | |
251 | # are cases in which is it useful but the user needs more control, | |
252 | # which they mostly have in GDB), but some people apparently think it | |
253 | # is a feature. It is documented in the ptrace manpage on Motorola | |
254 | # Delta Series sysV68 R3V7.1 and on HPUX 9.0. Even the non-HPUX PA | |
255 | # OSes (BSD and OSF/1) seem to have figured they had to copy this | |
256 | # braindamage. | |
257 | ||
258 | if {[ istarget "m68*-motorola-*" ] || [ istarget "hppa*-*-bsd*" ] || | |
259 | [ istarget "hppa*-*-osf*" ]} then { | |
78650829 AC |
260 | setup_xfail "*-*-*" |
261 | fail "ptrace loses on signals on this target" | |
262 | return 0 | |
c906108c SS |
263 | } |
264 | ||
78650829 AC |
265 | # lynx2.2.2 doesn't lose signals, instead it screws up the stack |
266 | # pointer in some of these tests leading to massive problems. I've | |
267 | # reported this to lynx, hopefully it'll be fixed in lynx2.3. Severe | |
268 | # braindamage. | |
269 | ||
c906108c | 270 | if [ istarget "*-*-*lynx*" ] then { |
78650829 AC |
271 | setup_xfail "*-*-*" |
272 | fail "kernel scroggs stack pointer in signal tests on this target" | |
273 | return 0 | |
c906108c SS |
274 | } |
275 | ||
276 | gdb_exit | |
277 | gdb_start | |
278 | ||
279 | # This will need to be updated as the exact list of signals changes, | |
280 | # but I want to test that TARGET_SIGNAL_0, TARGET_SIGNAL_DEFAULT, and | |
281 | # TARGET_SIGNAL_UNKNOWN are skipped. | |
78650829 | 282 | |
c906108c SS |
283 | proc test_handle_all_print {} { |
284 | global timeout | |
285 | # Increase timeout and expect input buffer for large output from gdb. | |
286 | # Allow blank or TAB as whitespace characters. | |
287 | set oldtimeout $timeout | |
288 | set timeout [expr "$timeout + 360"] | |
289 | verbose "Timeout is now $timeout seconds" 2 | |
7a292a7a SS |
290 | if { ![istarget "*-*-linux*"] |
291 | && ( [istarget "*-*-gnu*"] | |
292 | || [istarget "*-*-mach*"] ) } { | |
c906108c SS |
293 | 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" |
294 | } else { | |
104c1213 | 295 | 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.*" |
c906108c SS |
296 | } |
297 | set timeout $oldtimeout | |
298 | verbose "Timeout restored to $timeout seconds" 2 | |
299 | } | |
300 | test_handle_all_print | |
301 | ||
302 | gdb_exit | |
303 | gdb_start | |
304 | gdb_reinitialize_dir $srcdir/$subdir | |
305 | gdb_load $binfile | |
306 | signal_tests_1 | |
307 | ||
308 | # Force a resync, so we're looking at the right prompt. On SCO we | |
309 | # were getting out of sync (I don't understand why). | |
78650829 | 310 | |
c906108c SS |
311 | send_gdb "p 1+1\n" |
312 | gdb_expect { | |
78650829 AC |
313 | -re "= 2.*$gdb_prompt $" { |
314 | } | |
315 | -re ".*$gdb_prompt $" { | |
316 | perror "sync trouble in signals.exp" | |
317 | } | |
318 | default { | |
319 | perror "sync trouble in signals.exp" | |
320 | } | |
c906108c SS |
321 | } |
322 | ||
323 | if [runto_main] then { | |
78650829 AC |
324 | |
325 | # Since count is a static variable outside main, runto_main is no | |
326 | # guarantee that count will be 0 at this point. | |
327 | ||
b7844da6 | 328 | gdb_test "set variable count = 0" "" |
c906108c SS |
329 | gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*" |
330 | gdb_test "set \$handler_breakpoint_number = \$bpnum" "" | |
331 | ||
332 | # Get to the point where a signal is waiting to be delivered | |
78650829 | 333 | |
c906108c SS |
334 | gdb_test "next" "signal \\(SIGUSR1.*" "next to signal in signals.exp" |
335 | gdb_test "next" "alarm \\(.*" "next to alarm #1 in signals.exp" | |
336 | gdb_test "next" "\\+\\+count; /\\* first \\*/" \ | |
337 | "next to ++count #1 in signals.exp" | |
78650829 | 338 | |
c906108c | 339 | # Give the signal time to get delivered |
c906108c | 340 | |
78650829 AC |
341 | sleep 2 |
342 | ||
343 | # Now call a function. When GDB tries to run the stack dummy, it | |
344 | # will hit the breakpoint at handler. Provided it doesn't lose | |
345 | # its cool, this is not a problem, it just has to note that the | |
346 | # breakpoint condition is false and keep going. | |
c906108c | 347 | |
085dd6e6 | 348 | gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = $void" \ |
c906108c SS |
349 | "p func1 () #1 in signals.exp" |
350 | ||
351 | # Make sure the count got incremented. | |
352 | ||
353 | # Haven't investigated this xfail | |
78650829 | 354 | |
c906108c SS |
355 | setup_xfail "rs6000-*-*" |
356 | setup_xfail "powerpc-*-*" | |
357 | gdb_test "p count" "= 2" "p count #1 in signals.exp" | |
78650829 AC |
358 | if { [istarget "rs6000-*-*"] || [istarget "powerpc-*-*"] } { |
359 | return 0 | |
360 | } | |
c906108c SS |
361 | |
362 | gdb_test "condition \$handler_breakpoint_number" "now unconditional\\." | |
363 | gdb_test "next" "alarm \\(.*" "next to alarm #2 in signals.exp" | |
364 | gdb_test "next" "\\+\\+count; /\\* second \\*/" \ | |
365 | "next to ++count #2 in signals.exp" | |
366 | sleep 2 | |
367 | ||
78650829 AC |
368 | # This time we stop when GDB tries to run the stack dummy. So it |
369 | # is OK that we do not print the return value from the function. | |
370 | ||
c906108c SS |
371 | gdb_test "p func1 ()" \ |
372 | "Breakpoint \[0-9\]*, handler.* | |
373 | The program being debugged stopped while in a function called from GDB.*" \ | |
374 | "p func1 () #2 in signals.exp" | |
78650829 AC |
375 | |
376 | # But we should be able to backtrace... On alpha-*-osf2.0 this | |
377 | # test works when run manually but sometime fails when run under | |
378 | # dejagnu, making it very hard to debug the problem. Weird... | |
379 | ||
bea71854 | 380 | gdb_test "bt 10" "#0.*handler.*#1.*signal handler.*#2.* main .*" "bt in signals.exp" |
78650829 | 381 | |
c906108c | 382 | # ...and continue... |
78650829 | 383 | |
c906108c | 384 | gdb_test "continue" "Continuing\\." "continue in signals.exp" |
78650829 | 385 | |
c906108c | 386 | # ...and then count should have been incremented |
78650829 | 387 | |
c906108c SS |
388 | gdb_test "p count" "= 5" "p count #2 in signals.exp" |
389 | ||
390 | ||
78650829 AC |
391 | # Verify that "info signals" produces reasonable output. |
392 | ||
c906108c SS |
393 | send_gdb "info signals\n" |
394 | gdb_expect { | |
78650829 AC |
395 | -re "SIGHUP.*SIGINT.*SIGQUIT.*SIGILL.*SIGTRAP.*SIGABRT.*SIGEMT.*SIGFPE.*SIGKILL.*SIGBUS.*SIGSEGV.*SIGSYS.*SIGPIPE.*SIGALRM.*SIGTERM.*SIGURG.*SIGSTOP.*SIGTSTP.*SIGCONT.*SIGCHLD.*SIGTTIN.*SIGTTOU.*SIGIO.*SIGXCPU.*SIGXFSZ.*SIGVTALRM.*SIGPROF.*SIGWINCH.*SIGLOST.*SIGUSR1.*SIGUSR2.*SIGPWR.*SIGPOLL.*SIGWIND.*SIGPHONE.*SIGWAITING.*SIGLWP.*SIGDANGER.*SIGGRANT.*SIGRETRACT.*SIGMSG.*SIGSOUND.*SIGSAK.*SIGPRIO.*SIG33.*SIG34.*SIG35.*SIG36.*SIG37.*SIG38.*SIG39.*SIG40.*SIG41.*SIG42.*SIG43.*SIG44.*SIG45.*SIG46.*SIG47.*SIG48.*SIG49.*SIG50.*SIG51.*SIG52.*SIG53.*SIG54.*SIG55.*SIG56.*SIG57.*SIG58.*SIG59.*SIG60.*SIG61.*SIG62.*SIG63.*Use the \"handle\" command to change these tables.*$gdb_prompt $" { |
396 | pass "info signals" | |
397 | } | |
398 | -re "$gdb_prompt $" { | |
399 | fail "info signals" | |
400 | } | |
401 | timeout { | |
402 | fail "(timeout) info signals" | |
403 | } | |
c906108c SS |
404 | } |
405 | ||
78650829 AC |
406 | # Verify that "info signal" correctly handles an argument, be it a |
407 | # symbolic signal name, or an integer ID. | |
408 | ||
c906108c SS |
409 | send_gdb "info signal SIGTRAP\n" |
410 | gdb_expect { | |
78650829 AC |
411 | -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $" { |
412 | pass "info signal SIGTRAP" | |
413 | } | |
414 | -re "$gdb_prompt $" { | |
415 | fail "info signal SIGTRAP" | |
416 | } | |
417 | timeout { | |
418 | fail "(timeout) info signal SIGTRAP" | |
419 | } | |
c906108c SS |
420 | } |
421 | ||
422 | send_gdb "info signal 5\n" | |
423 | gdb_expect { | |
78650829 AC |
424 | -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $" { |
425 | pass "info signal 5" | |
426 | } | |
427 | -re "$gdb_prompt $" { | |
428 | fail "info signal 5" | |
429 | } | |
430 | timeout { | |
431 | fail "(timeout) info signal 5" | |
432 | } | |
c906108c SS |
433 | } |
434 | ||
78650829 AC |
435 | # Verify that "handle" with illegal arguments is gracefully, um, |
436 | # handled. | |
437 | ||
c906108c SS |
438 | send_gdb "handle\n" |
439 | gdb_expect { | |
78650829 AC |
440 | -re "Argument required .signal to handle.*$gdb_prompt $" { |
441 | pass "handle without arguments" | |
442 | } | |
443 | -re "$gdb_prompt $" { | |
444 | fail "handle without arguments" | |
445 | } | |
446 | timeout { | |
447 | fail "(timeout) handle without arguments" | |
448 | } | |
c906108c SS |
449 | } |
450 | ||
451 | send_gdb "handle SIGFOO\n" | |
452 | gdb_expect { | |
78650829 AC |
453 | -re "Unrecognized or ambiguous flag word: \"SIGFOO\".*$gdb_prompt $" { |
454 | pass "handle with bogus SIG" | |
455 | } | |
456 | -re "$gdb_prompt $" { | |
457 | fail "handle with bogus SIG" | |
458 | } | |
459 | timeout { | |
460 | fail "(timeout) handle with bogus SIG" | |
461 | } | |
c906108c SS |
462 | } |
463 | ||
464 | send_gdb "handle SIGHUP frump\n" | |
465 | gdb_expect { | |
78650829 AC |
466 | -re "Unrecognized or ambiguous flag word: \"frump\".*$gdb_prompt $" { |
467 | pass "handle SIG with bogus action" | |
468 | } | |
469 | -re "$gdb_prompt $" { | |
470 | fail "handle SIG with bogus action" | |
471 | } | |
472 | timeout { | |
473 | fail "(timeout) handle SIG with bogus action" | |
474 | } | |
c906108c SS |
475 | } |
476 | ||
78650829 AC |
477 | # Verify that "handle" can take multiple actions per SIG, and that |
478 | # in the case of conflicting actions, that the rightmost action | |
479 | # "wins". | |
480 | ||
c906108c SS |
481 | send_gdb "handle SIGHUP print noprint\n" |
482 | gdb_expect { | |
78650829 AC |
483 | -re ".*SIGHUP\[ \t\]*No\[ \t\]*No\[ \t\]*Yes\[ \t\]*Hangup.*$gdb_prompt $" { |
484 | pass "handle SIG with multiple conflicting actions" | |
485 | } | |
486 | -re "$gdb_prompt $" { | |
487 | fail "handle SIG with multiple conflicting actions" | |
488 | } | |
489 | timeout { | |
490 | fail "(timeout) handle SIG with multiple conflicting actions" | |
491 | } | |
c906108c SS |
492 | } |
493 | ||
78650829 AC |
494 | # Exercise all the various actions. (We don't care what the |
495 | # outcome is, this is just to ensure that they all can be parsed.) | |
496 | ||
c906108c SS |
497 | send_gdb "handle SIGHUP print noprint stop nostop ignore noignore pass nopass\n" |
498 | gdb_expect { | |
78650829 AC |
499 | -re ".*Signal.*$gdb_prompt $" { |
500 | pass "handle SIG parses all legal actions" | |
501 | } | |
502 | -re "$gdb_prompt $" { | |
503 | fail "handle SIG parses all legal actions" | |
504 | } | |
505 | timeout { | |
506 | fail "(timeout) handle SIG parses all legal actions" | |
507 | } | |
c906108c SS |
508 | } |
509 | ||
78650829 AC |
510 | # Verify that we can "handle" multiple signals at once, |
511 | # interspersed with actions. | |
512 | ||
c906108c SS |
513 | send_gdb "handle SIG63 print SIGILL\n" |
514 | gdb_expect { | |
78650829 AC |
515 | -re ".*SIGILL\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Illegal instruction.*SIG63\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Real-time event 63.*$gdb_prompt $" { |
516 | pass "handle multiple SIGs" | |
517 | } | |
518 | -re "$gdb_prompt $" { | |
519 | fail "handle multiple SIGs" | |
520 | } | |
521 | timeout { | |
522 | fail "(timeout) handle multiple SIGs" | |
523 | } | |
c906108c SS |
524 | } |
525 | ||
78650829 AC |
526 | # Verify that "handle" can take a numeric argument for the signal |
527 | # ID, rather than a symbolic name. (This may not be portable; | |
528 | # works for HP-UX.) | |
529 | ||
530 | # Also note that this testpoint overrides SIGTRAP, which on HP-UX | |
531 | # at least, is used to implement single-steps and breakpoints. | |
532 | # Don't expect to run the inferior after this! | |
533 | ||
c906108c SS |
534 | send_gdb "handle 5 nopass\n" |
535 | gdb_expect { | |
78650829 AC |
536 | -re ".*SIGTRAP is used by the debugger.*Are you sure you want to change it.*y or n.*" { |
537 | send_gdb "y\n" | |
538 | gdb_expect { | |
539 | -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $" { | |
540 | pass "override SIGTRAP (#5)" | |
541 | } | |
542 | -re "$gdb_prompt $" { | |
543 | fail "override SIGTRAP (#5)" | |
544 | } | |
545 | timeout { | |
546 | fail "(timeout) override SIGTRAP (#5)" | |
547 | } | |
548 | } | |
549 | } | |
550 | -re "$gdb_prompt $" { | |
551 | fail "override SIGTRAP (#5)" | |
552 | } | |
553 | timeout { | |
554 | fail "(timeout) override SIGTRAP (#5)" | |
555 | } | |
c906108c SS |
556 | } |
557 | ||
78650829 AC |
558 | # GDB doesn't seem to allow numeric signal IDs larger than 15. Verify |
559 | # that restriction. ??rehrauer: Not sure if this is a feature or a | |
560 | # bug, actually. Why is the range 1-15? | |
561 | ||
c906108c SS |
562 | send_gdb "handle 58\n" |
563 | gdb_expect { | |
78650829 AC |
564 | -re "Only signals 1-15 are valid as numeric signals.*Use \"info signals\" for a list of symbolic signals.*$gdb_prompt $" { |
565 | pass "invalid signal number rejected" | |
566 | } | |
567 | -re "$gdb_prompt $" { | |
568 | fail "invalid signal number rejected" | |
569 | } | |
570 | timeout { | |
571 | fail "(timeout) invalid signal number rejected" | |
572 | } | |
c906108c SS |
573 | } |
574 | ||
78650829 AC |
575 | # Verify that we can accept a signal ID range (number-number). |
576 | # ??rehrauer: This feature isn't documented on the quick-reference | |
577 | # card. | |
578 | ||
c906108c SS |
579 | send_gdb "handle 13-15\n" |
580 | gdb_expect { | |
78650829 AC |
581 | -re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $" { |
582 | pass "handle multiple SIGs via integer range" | |
583 | } | |
584 | -re "$gdb_prompt $" { | |
585 | fail "handle multiple SIGs via integer range" | |
586 | } | |
587 | timeout { | |
588 | fail "(timeout) handle multiple SIGs via integer range" | |
589 | } | |
c906108c SS |
590 | } |
591 | ||
78650829 AC |
592 | # Bizarrely enough, GDB also allows you to reverse the range stat, |
593 | # stop IDs. E.g., "3-1" and "1-3" mean the same thing. Probably | |
594 | # this isn't documented, but the code anticipates it, so we'd best | |
595 | # test it... | |
596 | ||
c906108c SS |
597 | send_gdb "handle 15-13\n" |
598 | gdb_expect { | |
78650829 AC |
599 | -re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $" { |
600 | pass "handle multiple SIGs via integer range" | |
601 | } | |
602 | -re "$gdb_prompt $" { | |
603 | fail "handle multiple SIGs via integer range" | |
604 | } | |
605 | timeout { | |
606 | fail "(timeout) handle multiple SIGs via integer range" | |
607 | } | |
c906108c SS |
608 | } |
609 | ||
78650829 AC |
610 | # SIGINT is used by the debugger as well. Verify that we can |
611 | # change our minds about changing it. | |
612 | ||
c906108c SS |
613 | send_gdb "handle SIGINT nopass\n" |
614 | gdb_expect { | |
78650829 AC |
615 | -re ".*SIGINT is used by the debugger.*Are you sure you want to change it.*y or n.*" { |
616 | send_gdb "n\n" | |
617 | # ??rehrauer: When you answer "n", the header for the | |
618 | # signal info is printed, but not the actual handler | |
619 | # settings. Probably a bug. | |
620 | gdb_expect { | |
621 | -re "Not confirmed, unchanged.*Signal.*$gdb_prompt $" { | |
622 | pass "override SIGINT" | |
623 | } | |
624 | -re "$gdb_prompt $" { | |
625 | fail "override SIGINT" | |
626 | } | |
627 | timeout { | |
628 | fail "(timeout) override SIGINT" | |
629 | } | |
630 | } | |
631 | } | |
632 | -re "$gdb_prompt $" { | |
633 | fail "override SIGINT" | |
634 | } | |
635 | timeout { | |
636 | fail "(timeout) override SIGINT" | |
637 | } | |
c906108c SS |
638 | } |
639 | ||
78650829 AC |
640 | # Verify that GDB responds gracefully to the "signal" command with |
641 | # a missing argument. | |
642 | ||
c906108c SS |
643 | send_gdb "signal\n" |
644 | gdb_expect { | |
78650829 AC |
645 | -re "Argument required .signal number..*$gdb_prompt $" { |
646 | pass "signal without arguments disallowed" | |
647 | } | |
648 | -re "$gdb_prompt $" { | |
649 | fail "signal without arguments disallowed" | |
650 | } | |
651 | timeout { | |
652 | fail "(timeout) signal without arguments disallowed" | |
653 | } | |
c906108c | 654 | } |
78650829 AC |
655 | |
656 | # Verify that we can successfully send a signal other than 0 to | |
657 | # the inferior. (This probably causes the inferior to run away. | |
658 | # Be prepared to rerun to main for further testing.) | |
c906108c | 659 | |
c906108c SS |
660 | send_gdb "signal 5\n" |
661 | gdb_expect { | |
78650829 AC |
662 | -re "Continuing with signal SIGTRAP.*$gdb_prompt $" { |
663 | pass "sent signal 5" | |
664 | } | |
665 | -re "$gdb_prompt $" { | |
666 | fail "sent signal 5" | |
667 | } | |
668 | timeout { | |
669 | fail "(timeout) sent signal 5" | |
670 | } | |
c906108c SS |
671 | } |
672 | ||
673 | } | |
674 | ||
675 | return 0 |