OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [gdb-5.0/] [gdb/] [testsuite/] [gdb.base/] [signals.exp] - Blame information for rev 1765

Details | Compare with Previous | View Log

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

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.