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