summaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.base/signals.exp
blob: 2bf719234bd7c896019a4ffcac84b158b12d95f8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
#   Copyright 1997, 1998, 1999 Free Software Foundation, Inc.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  

# Please email any bugs, comments, and/or additions to this file to:
# bug-gdb@prep.ai.mit.edu

if [target_info exists gdb,nosignals] {
    verbose "Skipping signals.exp because of nosignals."
    continue
}

if $tracelevel then {
	strace $tracelevel
}

set prms_id 0
set bug_id 0

set testfile signals
set srcfile ${testfile}.c
set binfile ${objdir}/${subdir}/${testfile}
if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
}

# Create and source the file that provides information about the compiler
# used to compile the test case.
if [get_compiler_info ${binfile}] {
    return -1;
}

if {$hp_cc_compiler} {
    set void 0
} else {
    set void void
}

proc signal_tests_1 {} {
    global gdb_prompt
    if [runto_main] then {
	gdb_test "next" "signal \\(SIGUSR1.*" \
		"next over signal (SIGALRM, handler)"
	gdb_test "next" "alarm \\(.*" \
		"next over signal (SIGUSR1, handler)"
	gdb_test "next" "\\+\\+count; /\\* first \\*/" \
		"next over alarm (1)"
	# An alarm has been signaled, give the signal time to get delivered.
	sleep 2

	# i386 BSD currently fails the next test with a SIGTRAP.
	setup_xfail "i*86-*-bsd*"
	# But Dynix has a DECR_PC_AFTER_BREAK of zero, so the failure
	# is shadowed by hitting the through_sigtramp_breakpoint.
	clear_xfail "i*86-sequent-bsd*"
	# Univel SVR4 i386 continues instead of stepping.
	setup_xfail "i*86-univel-sysv4*"
	# lynx fails with "next" acting like "continue"
	setup_xfail "*-*-*lynx*"
	# linux (aout versions) also fails with "next" acting like "continue"
	# this is probably more dependant on the kernel version than on the
	# object file format or utils.  (sigh)
	setup_xfail "i*86-pc-linuxaout-gnu" "i*86-pc-linuxoldld-gnu"
	send_gdb "next\n"
	gdb_expect {
	    -re "alarm .*$gdb_prompt $" { pass "next to 2nd alarm (1)" }
	    -re "Program received signal SIGTRAP.*first.*$gdb_prompt $" {

		# This can happen on machines that have a trace flag
		# in their PS register.
		# The trace flag in the PS register will be set due to
		# the `next' command.
		# Before calling the signal handler, the PS register
		# is pushed along with the context on the user stack.
		# When the signal handler has finished, it reenters the
		# the kernel via a sigreturn syscall, which restores the
		# PS register along with the context.
		# If the kernel erroneously does not clear the trace flag
		# in the pushed context, gdb will receive a SIGTRAP from
		# the set trace flag in the restored context after the
		# signal handler has finished.

		# I do not yet understand why the SIGTRAP does not occur
		# after stepping the instruction at the restored PC on
		# i386 BSDI 1.0 systems.

		# Note that the vax under Ultrix also exhibits
		# this behaviour (it is uncovered by the `continue from
		# a break in a signal handler' test below).
		# With this test the failure is shadowed by hitting the
		# through_sigtramp_breakpoint upon return from the signal
		# handler.

		# SVR4 and Linux based i*86 systems exhibit this behaviour
		# as well (it is uncovered by the `continue from a break
		# in a signal handler' test below).
		# As these systems use procfs, where we tell the kernel not
		# to tell gdb about `pass' signals, and the trace flag is
		# cleared by the kernel before entering the sigtramp
		# routine, GDB will not notice the execution of the signal 
		# handler.
		# Upon return from the signal handler, GDB will receive
		# a SIGTRAP from the set trace flag in the restored context.
		# The SIGTRAP marks the end of a (albeit long winded)
		# single step for GDB, causing this test to pass.

		fail "next to 2nd alarm (1) (probably kernel bug)"
		gdb_test "next" "alarm.*" "next to 2nd alarm (1)"
	    }
	    -re "Program exited with code.*$gdb_prompt $" {

		# This is apparently a bug in the UnixWare kernel (but
		# has not been investigated beyond the
		# resume/target_wait level, and has not been reported
		# to Univel).  If it steps when a signal is pending,
		# it does a continue instead.  I don't know whether
		# there is a workaround.

		# Perhaps this problem exists on other SVR4 systems;
		# but (a) we have no reason to think so, and (b) if we
		# put a wrong xfail here, we never get an XPASS to let
		# us know that it was incorrect (and then if such a
		# configuration regresses we have no way of knowing).
		# Solaris is not a relevant data point either way
		# because it lacks single stepping.

		# fnf: I don't agree with the above philosophy.  We
		# can never be sure that any particular XFAIL is
		# specified 100% correctly in that no systems with
		# the bug are missed and all systems without the bug
		# are excluded.  If we include an XFAIL that isn't
		# appropriate for a particular system, then when that
		# system gets tested it will XPASS, and someone should
		# investigate and fix the setup_xfail as appropriate,
		# or more preferably, the actual bug.  Each such case
		# adds more data to narrowing down the scope of the
		# problem and ultimately fixing it.

		setup_xfail "i*86-*-sysv4*"
		fail "'next' behaved as 'continue (known SVR4 bug)'"
		return 0
	    }
	    -re ".*$gdb_prompt $" { fail "next to 2nd alarm (1)" }
	    timeout { fail "next to 2nd alarm (1); (timeout)" }
	    eof { fail "next to 2nd alarm (1); (eof)" }
	}

	gdb_test "break handler" "Breakpoint \[0-9\]+ .*"
	gdb_test "next" "\\+\\+count; /\\* second \\*/" \
	    "next to 2nd ++count in signals_tests_1"
	# An alarm has been signaled, give the signal time to get delivered.
	sleep 2

	set bash_bug 0
	send_gdb "next\n"
	gdb_expect {
	    -re "Breakpoint.*handler.*$gdb_prompt $" {
		pass "next to handler in signals_tests_1"
	    }
	    -re "Program received signal SIGEMT.*$gdb_prompt $" {
		# Bash versions before 1.13.5 cause this behaviour
		# by blocking SIGTRAP.
		fail "next to handler in signals_tests_1 (known problem with bash versions before 1.13.5)"
		set bash_bug 1
		gdb_test "signal 0" "Breakpoint.*handler.*"
	    }
	    -re ".*$gdb_prompt $" { fail "next to handler in signals_tests_1" }
	    timeout { fail "next to handler in signals_tests_1 (timeout)" }
	    eof { fail "next to handler in signals_tests_1 (eof)" }
	}

	# This doesn't test that main is frame #2, just that main is frame
	# #2, #3, or higher.  At some point this should be fixed (but
	# it quite possibly would introduce new FAILs on some systems).
	setup_xfail "i*86-*-bsdi2.0"
	gdb_test "backtrace 10" "#0.*handler.*#1.*#2.*main.*" \
	    "backtrace in signals_tests_1"

	gdb_test "break func1" "Breakpoint \[0-9\]+ .*"
	gdb_test "break func2" "Breakpoint \[0-9\]+ .*"

	# Vax Ultrix and i386 BSD currently fail the next test with
	# a SIGTRAP, but with different symptoms.
	setup_xfail "vax-*-ultrix*"
	setup_xfail "i*86-*-bsd*"
	setup_xfail "i*86-pc-linux-gnu*"
	setup_xfail "i*86-*-solaris2*"
	send_gdb "continue\n"
	gdb_expect {
	    -re "Breakpoint.*func1.*$gdb_prompt $" { pass "continue to func1" }
	    -re "Program received signal SIGTRAP.*second.*$gdb_prompt $" {

		# See explanation for `next to 2nd alarm (1)' fail above.
		# We did step into the signal handler, hit a breakpoint
		# in the handler and continued from the breakpoint.
		# The set trace flag in the restored context is causing
		# the SIGTRAP, without stepping an instruction.

		fail "continue to func1 (probably kernel bug)"
		gdb_test "continue" "Breakpoint.*func1.*" \
		    "extra continue to func1"
	    }
	    -re "Program received signal SIGTRAP.*func1 ..;.*$gdb_prompt $" {

		# On the vax under Ultrix the set trace flag in the restored
		# context is causing the SIGTRAP, but after stepping one
		# instruction, as expected.

		fail "continue to func1 (probably kernel bug)"
		gdb_test "continue" "Breakpoint.*func1.*" \
		    "extra continue to func1"
	    }
	    -re ".*$gdb_prompt $" { fail "continue to func1" }
	    default { fail "continue to func1" }
	}

	setup_xfail "*-*-irix*"
	send_gdb "signal SIGUSR1\n"
	gdb_expect {
	    -re "Breakpoint.*handler.*$gdb_prompt $" { pass "signal SIGUSR1" }
	    -re "Program received signal SIGUSR1.*$gdb_prompt $" {
		# This is what irix4 and irix5 do.
		# It would appear to be a kernel bug.
		fail "signal SIGUSR1"
		gdb_test "continue" "Breakpoint.*handler.*" "pass it SIGUSR1"
	    }
	    -re ".*$gdb_prompt $" { fail "signal SIGUSR1" }
	    default { fail "signal SIGUSR1" }
	}

	# Will tend to wrongly require an extra continue.

	# The problem here is that the breakpoint at func1 will be
	# inserted, and when the system finishes with the signal
	# handler it will try to execute there.  For GDB to try to
	# remember that it was going to step over a breakpoint when a
	# signal happened, distinguish this case from the case where
	# func1 is called from the signal handler, etc., seems
	# exceedingly difficult.  So don't expect this to get fixed
	# anytime soon.

	setup_xfail "*-*-*"
	send_gdb "continue\n"
	gdb_expect {
	    -re "Breakpoint.*func2.*$gdb_prompt $" { pass "continue to func2" }
	    -re "Breakpoint.*func1.*$gdb_prompt $" {
	    	fail "continue to func2"
		gdb_test "continue" "Breakpoint.*func2.*" \
		    "extra continue to func2"
	    }
	    -re ".*$gdb_prompt $" { fail "continue to func2" }
	    default { fail "continue to func2" }
	}

	sleep 2

        # GDB yanks out the breakpoints to step over the breakpoint it
        # stopped at, which means the breakpoint at handler is yanked.
	# But if SOFTWARE_SINGLE_STEP_P, we won't get another chance to
	# reinsert them (at least not with procfs, where we tell the kernel
	# not to tell gdb about `pass' signals).  So the fix would appear to
	# be to just yank that one breakpoint when we step over it.

	setup_xfail "sparc*-*-*"
	setup_xfail "rs6000-*-*"
	setup_xfail "powerpc-*-*"

	# A faulty bash will not step the inferior into sigtramp on sun3.
	if {$bash_bug} then {
	    setup_xfail "m68*-*-sunos4*"
	}

	setup_xfail "i*86-pc-linux-gnu*"
	setup_xfail "i*86-*-solaris2*"
	gdb_test "continue" "Breakpoint.*handler.*" "continue to handler"

	# If the SOFTWARE_SINGLE_STEP_P failure happened, we have already
	# exited.
        # If we succeeded a continue will return from the handler to func2.
	# GDB now has `forgotten' that it intended to step over the
	# breakpoint at func2 and will stop at func2.
	setup_xfail "*-*-*"
	# The sun3 with a faulty bash will also be `forgetful' but it
	# already got the spurious stop at func2 and this continue will work.
	if {$bash_bug} then {
	     clear_xfail "m68*-*-sunos4*"
	}
	gdb_test "continue" "Program exited with code 010\\." \
	    "continue to exit in signals_tests_1 "
    }
}

# On a few losing systems, ptrace (PT_CONTINUE) or ptrace (PT_STEP)
# causes pending signals to be cleared, which causes these tests to
# get nowhere fast.  This is totally losing behavior (perhaps there
# are cases in which is it useful but the user needs more control,
# which they mostly have in GDB), but some people apparently think it
# is a feature.  It is documented in the ptrace manpage on Motorola
# Delta Series sysV68 R3V7.1 and on HPUX 9.0.  Even the non-HPUX PA
# OSes (BSD and OSF/1) seem to have figured they had to copy this
# braindamage.

if {[ istarget "m68*-motorola-*" ] || [ istarget "hppa*-*-bsd*" ] ||
    [ istarget "hppa*-*-osf*" ]} then {
  setup_xfail "*-*-*"
  fail "ptrace loses on signals on this target"
  return 0
}

# lynx2.2.2 doesn't lose signals, instead it screws up the stack pointer
# in some of these tests leading to massive problems.  I've
# reported this to lynx, hopefully it'll be fixed in lynx2.3.
# Severe braindamage.
if [ istarget "*-*-*lynx*" ] then {
  setup_xfail "*-*-*"
  fail "kernel scroggs stack pointer in signal tests on this target"
  return 0
}

gdb_exit
gdb_start

# This will need to be updated as the exact list of signals changes,
# but I want to test that TARGET_SIGNAL_0, TARGET_SIGNAL_DEFAULT, and
# TARGET_SIGNAL_UNKNOWN are skipped.
proc test_handle_all_print {} {
    global timeout
    # Increase timeout and expect input buffer for large output from gdb.
    # Allow blank or TAB as whitespace characters.
    set oldtimeout $timeout
    set timeout [expr "$timeout + 360"]
    verbose "Timeout is now $timeout seconds" 2
    if { ![istarget "*-*-linux*"]
         && ( [istarget "*-*-gnu*"]
              || [istarget "*-*-mach*"] ) } {
	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"
    } else {
	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.*"
    }
    set timeout $oldtimeout
    verbose "Timeout restored to $timeout seconds" 2
}
test_handle_all_print

gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load $binfile
signal_tests_1

# Force a resync, so we're looking at the right prompt.  On SCO we
# were getting out of sync (I don't understand why).
send_gdb "p 1+1\n"
gdb_expect {
    -re "= 2.*$gdb_prompt $" {}
    -re ".*$gdb_prompt $" { perror "sync trouble in signals.exp" }
    default { perror "sync trouble in signals.exp" }
}

if [runto_main] then {
    # Since count is a static variable outside main, runto_main
    # is no guarantee that count will be 0 at this point.
    gdb_test "set variable count = 0" ""
    gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*"
    gdb_test "set \$handler_breakpoint_number = \$bpnum" ""

    # Get to the point where a signal is waiting to be delivered
    gdb_test "next" "signal \\(SIGUSR1.*" "next to signal in signals.exp"
    gdb_test "next" "alarm \\(.*" "next to alarm #1 in signals.exp"
    gdb_test "next" "\\+\\+count; /\\* first \\*/" \
	"next to ++count #1 in signals.exp"
    # Give the signal time to get delivered
    sleep 2

    # Now call a function.  When GDB tries to run the stack dummy,
    # it will hit the breakpoint at handler.  Provided it doesn't
    # lose its cool, this is not a problem, it just has to note
    # that the breakpoint condition is false and keep going.

    gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = $void" \
	"p func1 () #1 in signals.exp"

    # Make sure the count got incremented.

    # Haven't investigated this xfail
    setup_xfail "rs6000-*-*"
    setup_xfail "powerpc-*-*"
    gdb_test "p count" "= 2" "p count #1 in signals.exp"
    if { [istarget "rs6000-*-*"] || [istarget "powerpc-*-*"] } { return 0 }

    gdb_test "condition \$handler_breakpoint_number" "now unconditional\\."
    gdb_test "next" "alarm \\(.*" "next to alarm #2 in signals.exp"
    gdb_test "next" "\\+\\+count; /\\* second \\*/" \
	"next to ++count #2 in signals.exp"
    sleep 2

    # This time we stop when GDB tries to run the stack dummy.
    # So it is OK that we do not print the return value from the function.
    gdb_test "p func1 ()" \
"Breakpoint \[0-9\]*, handler.*
The program being debugged stopped while in a function called from GDB.*" \
	"p func1 () #2 in signals.exp"
    # But we should be able to backtrace...
    # On alpha-*-osf2.0 this test works when run manually but sometime fails when
    # run under dejagnu, making it very hard to debug the problem.  Weird...
    gdb_test "bt 10" "#0.*handler.*#1.*#2.*main.*" "bt in signals.exp"
    # ...and continue...
    gdb_test "continue" "Continuing\\." "continue in signals.exp"
    # ...and then count should have been incremented
    gdb_test "p count" "= 5" "p count #2 in signals.exp"


# Verify that "info signals" produces reasonable output.
#
    send_gdb "info signals\n"
    gdb_expect {
      -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 $"\
              {pass "info signals"}
      -re "$gdb_prompt $"\
              {fail "info signals"}
      timeout {fail "(timeout) info signals"}
    }

# Verify that "info signal" correctly handles an argument, be it a
# symbolic signal name, or an integer ID.
#
    send_gdb "info signal SIGTRAP\n"
    gdb_expect {
      -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\
              {pass "info signal SIGTRAP"}
      -re "$gdb_prompt $"\
              {fail "info signal SIGTRAP"}
      timeout {fail "(timeout) info signal SIGTRAP"}
    }

    send_gdb "info signal 5\n"
    gdb_expect {
      -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\
              {pass "info signal 5"}
      -re "$gdb_prompt $"\
              {fail "info signal 5"}
      timeout {fail "(timeout) info signal 5"}
    }

# Verify that "handle" with illegal arguments is gracefully, um, handled.
#
    send_gdb "handle\n"
    gdb_expect {
      -re "Argument required .signal to handle.*$gdb_prompt $"\
              {pass "handle without arguments"}
      -re "$gdb_prompt $"\
              {fail "handle without arguments"}
      timeout {fail "(timeout) handle without arguments"}
    }

    send_gdb "handle SIGFOO\n"
    gdb_expect {
      -re "Unrecognized or ambiguous flag word: \"SIGFOO\".*$gdb_prompt $"\
              {pass "handle with bogus SIG"}
      -re "$gdb_prompt $"\
              {fail "handle with bogus SIG"}
      timeout {fail "(timeout) handle with bogus SIG"}
    }

    send_gdb "handle SIGHUP frump\n"
    gdb_expect {
      -re "Unrecognized or ambiguous flag word: \"frump\".*$gdb_prompt $"\
              {pass "handle SIG with bogus action"}
      -re "$gdb_prompt $"\
              {fail "handle SIG with bogus action"}
      timeout {fail "(timeout) handle SIG with bogus action"}
    }

# Verify that "handle" can take multiple actions per SIG, and that in
# the case of conflicting actions, that the rightmost action "wins".
#
    send_gdb "handle SIGHUP print noprint\n"
    gdb_expect {
      -re ".*SIGHUP\[ \t\]*No\[ \t\]*No\[ \t\]*Yes\[ \t\]*Hangup.*$gdb_prompt $"\
              {pass "handle SIG with multiple conflicting actions"}
      -re "$gdb_prompt $"\
              {fail "handle SIG with multiple conflicting actions"}
      timeout {fail "(timeout) handle SIG with multiple conflicting actions"}
    }

# Exercise all the various actions.  (We don't care what the outcome
# is, this is just to ensure that they all can be parsed.)
#
    send_gdb "handle SIGHUP print noprint stop nostop ignore noignore pass nopass\n"
    gdb_expect {
      -re ".*Signal.*$gdb_prompt $"\
              {pass "handle SIG parses all legal actions"}
      -re "$gdb_prompt $"\
              {fail "handle SIG parses all legal actions"}
      timeout {fail "(timeout) handle SIG parses all legal actions"}
    }

# Verify that we can "handle" multiple signals at once, interspersed
# with actions.
#
    send_gdb "handle SIG63 print SIGILL\n"
    gdb_expect {
      -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 $"\
              {pass "handle multiple SIGs"}
      -re "$gdb_prompt $"\
              {fail "handle multiple SIGs"}
      timeout {fail "(timeout) handle multiple SIGs"}
    }

# Verify that "handle" can take a numeric argument for the signal ID,
# rather than a symbolic name.  (This may not be portable; works for
# HP-UX.)
#
# Also note that this testpoint overrides SIGTRAP, which on HP-UX at
# least, is used to implement single-steps and breakpoints.  Don't
# expect to run the inferior after this!
#
    send_gdb "handle 5 nopass\n"
    gdb_expect {
      -re ".*SIGTRAP is used by the debugger.*Are you sure you want to change it.*y or n.*"\
              {send_gdb "y\n"
               gdb_expect {
                 -re ".*SIGTRAP\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*No\[ \t\]*Trace/breakpoint trap.*$gdb_prompt $"\
                         {pass "override SIGTRAP (#5)"}
                 -re "$gdb_prompt $"\
                         {fail "override SIGTRAP (#5)"}
                 timeout {fail "(timeout) override SIGTRAP (#5)"}
               }
              }
      -re "$gdb_prompt $"\
              {fail "override SIGTRAP (#5)"}
      timeout {fail "(timeout) override SIGTRAP (#5)"}
    }

# GDB doesn't seem to allow numeric signal IDs larger than 15.  Verify
# that restriction.  ??rehrauer: Not sure if this is a feature or a
# bug, actually.  Why is the range 1-15?
#
    send_gdb "handle 58\n"
    gdb_expect {
      -re "Only signals 1-15 are valid as numeric signals.*Use \"info signals\" for a list of symbolic signals.*$gdb_prompt $"\
              {pass "invalid signal number rejected"}
      -re "$gdb_prompt $"\
              {fail "invalid signal number rejected"}
      timeout {fail "(timeout) invalid signal number rejected"}
    }

# Verify that we can accept a signal ID range (number-number).
# ??rehrauer: This feature isn't documented on the quick-reference
# card.
#
    send_gdb "handle 13-15\n"
    gdb_expect {
      -re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $"\
              {pass "handle multiple SIGs via integer range"}
      -re "$gdb_prompt $"\
              {fail "handle multiple SIGs via integer range"}
      timeout {fail "(timeout) handle multiple SIGs via integer range"}

    }

# Bizarrely enough, GDB also allows you to reverse the range
# stat, stop IDs.  E.g., "3-1" and "1-3" mean the same thing.
# Probably this isn't documented, but the code anticipates it,
# so we'd best test it...
#
    send_gdb "handle 15-13\n"
    gdb_expect {
      -re ".*SIGPIPE.*SIGALRM.*SIGTERM.*$gdb_prompt $"\
              {pass "handle multiple SIGs via integer range"}
      -re "$gdb_prompt $"\
              {fail "handle multiple SIGs via integer range"}
      timeout {fail "(timeout) handle multiple SIGs via integer range"}

    }

# SIGINT is used by the debugger as well.  Verify that we can change
# our minds about changing it.
#
    send_gdb "handle SIGINT nopass\n"
    gdb_expect {
      -re ".*SIGINT is used by the debugger.*Are you sure you want to change it.*y or n.*"\
              {send_gdb "n\n"
# ??rehrauer: When you answer "n", the header for the signal info is
# printed, but not the actual handler settings.  Probably a bug.
#
               gdb_expect {
                 -re "Not confirmed, unchanged.*Signal.*$gdb_prompt $"\
                         {pass "override SIGINT"}
                 -re "$gdb_prompt $"\
                         {fail "override SIGINT"}
                 timeout {fail "(timeout) override SIGINT"}
               }
              }
      -re "$gdb_prompt $"\
              {fail "override SIGINT"}
      timeout {fail "(timeout) override SIGINT"}
    }

# Verify that GDB responds gracefully to the "signal" command with
# a missing argument.
#
    send_gdb "signal\n"
    gdb_expect {
      -re "Argument required .signal number..*$gdb_prompt $"\
              {pass "signal without arguments disallowed"}
      -re "$gdb_prompt $"\
              {fail "signal without arguments disallowed"}
      timeout {fail "(timeout) signal without arguments disallowed"}
    }

# Verify that we can successfully send a signal other than 0 to
# the inferior.  (This probably causes the inferior to run away.
# Be prepared to rerun to main for further testing.)
#
    send_gdb "signal 5\n"
    gdb_expect {
      -re "Continuing with signal SIGTRAP.*$gdb_prompt $"\
              {pass "sent signal 5"}
      -re "$gdb_prompt $"\
              {fail "sent signal 5"}
      timeout {fail "(timeout) sent signal 5"}
    }

}

return 0