[deliverable/binutils-gdb.git] / gdb / testsuite / gdb.base / signals.exp

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}] != "" } {
    perror "Couldn't compile ${srcfile}"
    return -1
}

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

proc signal_tests_1 {} {
    global 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"
	expect {
	    -re "alarm .*$prompt $" { pass "next to 2nd alarm (1)" }
	    -re "Program received signal SIGTRAP.*first.*$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.

		fail "next to 2nd alarm (1) (probably kernel bug)"
		gdb_test "next" "alarm.*" "next to 2nd alarm (1)"
	    }
	    -re "Program exited with code.*$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 ".*$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"
	setup_xfail "i*86-pc-linux-gnu"
	expect {
	    -re "Breakpoint.*handler.*$prompt $" {
		pass "next to handler in signals_tests_1"
	    }
	    -re "Program received signal SIGEMT.*$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 ".*$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-pc-linux-gnu" "i*86-*-bsdi2.0"
	gdb_test "backtrace" "#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"
	send_gdb "continue\n"
	expect {
	    -re "Breakpoint.*func1.*$prompt $" { pass "continue to func1" }
	    -re "Program received signal SIGTRAP.*second.*$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 ..;.*$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 ".*$prompt $" { fail "continue to func1" }
	    default { fail "continue to func1" }
	}

	setup_xfail "*-*-irix*"
	send_gdb "signal SIGUSR1\n"
	expect {
	    -re "Breakpoint.*handler.*$prompt $" { pass "signal SIGUSR1" }
	    -re "Program received signal SIGUSR1.*$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 ".*$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"
	expect {
	    -re "Breakpoint.*func2.*$prompt $" { pass "continue to func2" }
	    -re "Breakpoint.*func1.*$prompt $" {
	    	fail "continue to func2"
		gdb_test "continue" "Breakpoint.*func2.*" \
		    "extra continue to func2"
	    }
	    -re ".*$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 NO_SINGLE_STEP, 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"
	gdb_test "continue" "Breakpoint.*handler.*" "continue to handler"

	# If the NO_SINGLE_STEP 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 "*-*-hpux*" ] || [ 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
    match_max 10000
    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"
    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"
expect {
    -re "= 2.*$prompt $" {}
    -re ".*$prompt $" { perror "sync trouble in signals.exp" }
    default { perror "sync trouble in signals.exp" }
}

if [runto_main] then {
    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" "#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"
}

return 0
Commit	Line	Data
1a7dadf9 BM	1	if [target_info exists gdb,nosignals] {
	2	verbose "Skipping signals.exp because of nosignals."
	3	continue
	4	}
2f11e8d4 JL	5
	6	if $tracelevel then {
	7	strace $tracelevel
	8	}
	9
	10	set prms_id 0
	11	set bug_id 0
	12
782445c7	13	set testfile signals
8a25c34c	14	set srcfile ${testfile}.c
782445c7	15	set binfile ${objdir}/${subdir}/${testfile}
787f6220	16	if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
782445c7 FF	17	perror "Couldn't compile ${srcfile}"
782445c7 FF	18	return -1
2f11e8d4 JL	19	}
2f11e8d4 JL	20
a26fa899 FF	21	# Create and source the file that provides information about the compiler
a26fa899 FF	22	# used to compile the test case.
787f6220 BM	23	if [get_compiler_info ${binfile}] {
787f6220 BM	24	return -1;
8a25c34c	25	}
8a25c34c	26
2f11e8d4 JL	27	proc signal_tests_1 {} {
	28	global prompt
	29	if [runto_main] then {
	30	gdb_test "next" "signal \\(SIGUSR1.*" \
	31	"next over signal (SIGALRM, handler)"
	32	gdb_test "next" "alarm \\(.*" \
	33	"next over signal (SIGUSR1, handler)"
	34	gdb_test "next" "\\+\\+count; /\\* first \\*/" \
	35	"next over alarm (1)"
	36	# An alarm has been signaled, give the signal time to get delivered.
787f6220	37	sleep 2
2f11e8d4 JL	38
	39	# i386 BSD currently fails the next test with a SIGTRAP.
	40	setup_xfail "i86--bsd*"
	41	# But Dynix has a DECR_PC_AFTER_BREAK of zero, so the failure
	42	# is shadowed by hitting the through_sigtramp_breakpoint.
	43	clear_xfail "i86-sequent-bsd"
	44	# Univel SVR4 i386 continues instead of stepping.
	45	setup_xfail "i86-univel-sysv4"
	46	# lynx fails with "next" acting like "continue"
	47	setup_xfail "--lynx"
db186b3d FF	48	# linux (aout versions) also fails with "next" acting like "continue"
	49	# this is probably more dependant on the kernel version than on the
	50	# object file format or utils. (sigh)
787f6220 BM	51	setup_xfail "i86-pc-linuxaout-gnu" "i86-pc-linuxoldld-gnu"
787f6220 BM	52	send_gdb "next\n"
2f11e8d4 JL	53	expect {
	54	-re "alarm .*$prompt $" { pass "next to 2nd alarm (1)" }
	55	-re "Program received signal SIGTRAP.first.$prompt $" {
	56
	57	# This can happen on machines that have a trace flag
	58	# in their PS register.
	59	# The trace flag in the PS register will be set due to
	60	# the `next' command.
	61	# Before calling the signal handler, the PS register
	62	# is pushed along with the context on the user stack.
	63	# When the signal handler has finished, it reenters the
	64	# the kernel via a sigreturn syscall, which restores the
	65	# PS register along with the context.
	66	# If the kernel erroneously does not clear the trace flag
	67	# in the pushed context, gdb will receive a SIGTRAP from
	68	# the set trace flag in the restored context after the
	69	# signal handler has finished.
	70
	71	# I do not yet understand why the SIGTRAP does not occur
	72	# after stepping the instruction at the restored PC on
	73	# i386 BSDI 1.0 systems.
	74
	75	# Note that the vax under Ultrix also exhibits
	76	# this behaviour (it is uncovered by the `continue from
	77	# a break in a signal handler' test below).
	78	# With this test the failure is shadowed by hitting the
	79	# through_sigtramp_breakpoint upon return from the signal
	80	# handler.
	81
	82	fail "next to 2nd alarm (1) (probably kernel bug)"
	83	gdb_test "next" "alarm.*" "next to 2nd alarm (1)"
	84	}
	85	-re "Program exited with code.*$prompt $" {
	86
	87	# This is apparently a bug in the UnixWare kernel (but
	88	# has not been investigated beyond the
	89	# resume/target_wait level, and has not been reported
	90	# to Univel). If it steps when a signal is pending,
	91	# it does a continue instead. I don't know whether
	92	# there is a workaround.
	93
	94	# Perhaps this problem exists on other SVR4 systems;
	95	# but (a) we have no reason to think so, and (b) if we
	96	# put a wrong xfail here, we never get an XPASS to let
	97	# us know that it was incorrect (and then if such a
	98	# configuration regresses we have no way of knowing).
	99	# Solaris is not a relevant data point either way
	100	# because it lacks single stepping.
	101
06c87bef FF	102	# fnf: I don't agree with the above philosophy. We
	103	# can never be sure that any particular XFAIL is
	104	# specified 100% correctly in that no systems with
	105	# the bug are missed and all systems without the bug
	106	# are excluded. If we include an XFAIL that isn't
	107	# appropriate for a particular system, then when that
	108	# system gets tested it will XPASS, and someone should
	109	# investigate and fix the setup_xfail as appropriate,
	110	# or more preferably, the actual bug. Each such case
	111	# adds more data to narrowing down the scope of the
	112	# problem and ultimately fixing it.
	113
	114	setup_xfail "i86--sysv4*"
	115	fail "'next' behaved as 'continue (known SVR4 bug)'"
2f11e8d4 JL	116	return 0
	117	}
	118	-re ".*$prompt $" { fail "next to 2nd alarm (1)" }
	119	timeout { fail "next to 2nd alarm (1); (timeout)" }
	120	eof { fail "next to 2nd alarm (1); (eof)" }
	121	}
	122
	123	gdb_test "break handler" "Breakpoint \[0-9\]+ .*"
	124	gdb_test "next" "\\+\\+count; /\\* second \\*/" \
	125	"next to 2nd ++count in signals_tests_1"
	126	# An alarm has been signaled, give the signal time to get delivered.
787f6220	127	sleep 2
2f11e8d4 JL	128
2f11e8d4 JL	129	set bash_bug 0
787f6220 BM	130	send_gdb "next\n"
787f6220 BM	131	setup_xfail "i*86-pc-linux-gnu"
2f11e8d4 JL	132	expect {
	133	-re "Breakpoint.handler.$prompt $" {
	134	pass "next to handler in signals_tests_1"
	135	}
	136	-re "Program received signal SIGEMT.*$prompt $" {
	137	# Bash versions before 1.13.5 cause this behaviour
	138	# by blocking SIGTRAP.
	139	fail "next to handler in signals_tests_1 (known problem with bash versions before 1.13.5)"
	140	set bash_bug 1
	141	gdb_test "signal 0" "Breakpoint.handler."
	142	}
	143	-re ".*$prompt $" { fail "next to handler in signals_tests_1" }
	144	timeout { fail "next to handler in signals_tests_1 (timeout)" }
	145	eof { fail "next to handler in signals_tests_1 (eof)" }
	146	}
	147
	148	# This doesn't test that main is frame #2, just that main is frame
	149	# #2, #3, or higher. At some point this should be fixed (but
	150	# it quite possibly would introduce new FAILs on some systems).
787f6220	151	setup_xfail "i86-pc-linux-gnu" "i86-*-bsdi2.0"
2f11e8d4 JL	152	gdb_test "backtrace" "#0.handler.#1.#2.main.*" \
	153	"backtrace in signals_tests_1"
	154
	155	gdb_test "break func1" "Breakpoint \[0-9\]+ .*"
	156	gdb_test "break func2" "Breakpoint \[0-9\]+ .*"
	157
	158	# Vax Ultrix and i386 BSD currently fail the next test with
	159	# a SIGTRAP, but with different symptoms.
	160	setup_xfail "vax--ultrix"
	161	setup_xfail "i86--bsd*"
787f6220 BM	162	setup_xfail "i*86-pc-linux-gnu"
787f6220 BM	163	send_gdb "continue\n"
2f11e8d4 JL	164	expect {
	165	-re "Breakpoint.func1.$prompt $" { pass "continue to func1" }
	166	-re "Program received signal SIGTRAP.second.$prompt $" {
	167
	168	# See explanation for `next to 2nd alarm (1)' fail above.
	169	# We did step into the signal handler, hit a breakpoint
	170	# in the handler and continued from the breakpoint.
	171	# The set trace flag in the restored context is causing
	172	# the SIGTRAP, without stepping an instruction.
	173
	174	fail "continue to func1 (probably kernel bug)"
	175	gdb_test "continue" "Breakpoint.func1." \
	176	"extra continue to func1"
	177	}
	178	-re "Program received signal SIGTRAP.func1 ..;.$prompt $" {
	179
	180	# On the vax under Ultrix the set trace flag in the restored
	181	# context is causing the SIGTRAP, but after stepping one
	182	# instruction, as expected.
	183
	184	fail "continue to func1 (probably kernel bug)"
	185	gdb_test "continue" "Breakpoint.func1." \
	186	"extra continue to func1"
	187	}
	188	-re ".*$prompt $" { fail "continue to func1" }
	189	default { fail "continue to func1" }
	190	}
	191
	192	setup_xfail "--irix*"
787f6220	193	send_gdb "signal SIGUSR1\n"
2f11e8d4 JL	194	expect {
	195	-re "Breakpoint.handler.$prompt $" { pass "signal SIGUSR1" }
	196	-re "Program received signal SIGUSR1.*$prompt $" {
	197	# This is what irix4 and irix5 do.
	198	# It would appear to be a kernel bug.
	199	fail "signal SIGUSR1"
	200	gdb_test "continue" "Breakpoint.handler." "pass it SIGUSR1"
	201	}
	202	-re ".*$prompt $" { fail "signal SIGUSR1" }
	203	default { fail "signal SIGUSR1" }
	204	}
	205
	206	# Will tend to wrongly require an extra continue.
	207
	208	# The problem here is that the breakpoint at func1 will be
	209	# inserted, and when the system finishes with the signal
	210	# handler it will try to execute there. For GDB to try to
	211	# remember that it was going to step over a breakpoint when a
	212	# signal happened, distinguish this case from the case where
	213	# func1 is called from the signal handler, etc., seems
	214	# exceedingly difficult. So don't expect this to get fixed
	215	# anytime soon.
	216
	217	setup_xfail "--*"
787f6220	218	send_gdb "continue\n"
2f11e8d4 JL	219	expect {
	220	-re "Breakpoint.func2.$prompt $" { pass "continue to func2" }
	221	-re "Breakpoint.func1.$prompt $" {
	222	fail "continue to func2"
	223	gdb_test "continue" "Breakpoint.func2." \
	224	"extra continue to func2"
	225	}
	226	-re ".*$prompt $" { fail "continue to func2" }
	227	default { fail "continue to func2" }
	228	}
	229
787f6220	230	sleep 2
2f11e8d4 JL	231
	232	# GDB yanks out the breakpoints to step over the breakpoint it
	233	# stopped at, which means the breakpoint at handler is yanked.
	234	# But if NO_SINGLE_STEP, we won't get another chance to reinsert
	235	# them (at least not with procfs, where we tell the kernel not
	236	# to tell gdb about `pass' signals). So the fix would appear to
	237	# be to just yank that one breakpoint when we step over it.
	238
8a25c34c	239	setup_xfail "sparc--*"
2f11e8d4	240	setup_xfail "rs6000--"
5c6f833b	241	setup_xfail "powerpc--"
2f11e8d4 JL	242
	243	# A faulty bash will not step the inferior into sigtramp on sun3.
	244	if {$bash_bug} then {
	245	setup_xfail "m68--sunos4*"
	246	}
	247
787f6220	248	setup_xfail "i*86-pc-linux-gnu"
2f11e8d4 JL	249	gdb_test "continue" "Breakpoint.handler." "continue to handler"
	250
	251	# If the NO_SINGLE_STEP failure happened, we have already exited.
	252	# If we succeeded a continue will return from the handler to func2.
	253	# GDB now has `forgotten' that it intended to step over the
	254	# breakpoint at func2 and will stop at func2.
	255	setup_xfail "--*"
	256	# The sun3 with a faulty bash will also be `forgetful' but it
	257	# already got the spurious stop at func2 and this continue will work.
	258	if {$bash_bug} then {
	259	clear_xfail "m68--sunos4*"
	260	}
	261	gdb_test "continue" "Program exited with code 010\\." \
	262	"continue to exit in signals_tests_1 "
	263	}
	264	}
	265
	266	# On a few losing systems, ptrace (PT_CONTINUE) or ptrace (PT_STEP)
	267	# causes pending signals to be cleared, which causes these tests to
	268	# get nowhere fast. This is totally losing behavior (perhaps there
	269	# are cases in which is it useful but the user needs more control,
	270	# which they mostly have in GDB), but some people apparently think it
	271	# is a feature. It is documented in the ptrace manpage on Motorola
	272	# Delta Series sysV68 R3V7.1 and on HPUX 9.0. Even the non-HPUX PA
	273	# OSes (BSD and OSF/1) seem to have figured they had to copy this
	274	# braindamage.
	275
	276	if {[ istarget "m68-motorola-" ] \|\| [ istarget "hppa--bsd*" ] \|\|
	277	[ istarget "--hpux" ] \|\| [ istarget "hppa--osf" ]} then {
	278	setup_xfail "--*"
	279	fail "ptrace loses on signals on this target"
	280	return 0
	281	}
	282
8b67f01d JL	283	# lynx2.2.2 doesn't lose signals, instead it screws up the stack pointer
	284	# in some of these tests leading to massive problems. I've
	285	# reported this to lynx, hopefully it'll be fixed in lynx2.3.
	286	# Severe braindamage.
	287	if [ istarget "--lynx" ] then {
	288	setup_xfail "--*"
	289	fail "kernel scroggs stack pointer in signal tests on this target"
db186b3d	290	return 0
8b67f01d JL	291	}
8b67f01d JL	292
2f11e8d4 JL	293	gdb_exit
	294	gdb_start
	295
	296	# This will need to be updated as the exact list of signals changes,
	297	# but I want to test that TARGET_SIGNAL_0, TARGET_SIGNAL_DEFAULT, and
	298	# TARGET_SIGNAL_UNKNOWN are skipped.
782445c7	299	proc test_handle_all_print {} {
787f6220 BM	300	global timeout
	301	# Increase timeout and expect input buffer for large output from gdb.
	302	# Allow blank or TAB as whitespace characters.
	303	set oldtimeout $timeout
	304	set timeout [expr "$timeout + 360"]
	305	verbose "Timeout is now $timeout seconds" 2
5fac6a39	306	match_max 10000
787f6220 BM	307	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"
	308	set timeout $oldtimeout
	309	verbose "Timeout restored to $timeout seconds" 2
782445c7 FF	310	}
782445c7 FF	311	test_handle_all_print
2f11e8d4 JL	312
	313	gdb_exit
	314	gdb_start
	315	gdb_reinitialize_dir $srcdir/$subdir
	316	gdb_load $binfile
	317	signal_tests_1
	318
	319	# Force a resync, so we're looking at the right prompt. On SCO we
	320	# were getting out of sync (I don't understand why).
787f6220	321	send_gdb "p 1+1\n"
2f11e8d4 JL	322	expect {
	323	-re "= 2.*$prompt $" {}
	324	-re ".*$prompt $" { perror "sync trouble in signals.exp" }
	325	default { perror "sync trouble in signals.exp" }
	326	}
	327
	328	if [runto_main] then {
	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
	333	gdb_test "next" "signal \\(SIGUSR1.*" "next to signal in signals.exp"
	334	gdb_test "next" "alarm \\(.*" "next to alarm #1 in signals.exp"
	335	gdb_test "next" "\\+\\+count; /\\* first \\*/" \
	336	"next to ++count #1 in signals.exp"
	337	# Give the signal time to get delivered
787f6220	338	sleep 2
2f11e8d4 JL	339
	340	# Now call a function. When GDB tries to run the stack dummy,
	341	# it will hit the breakpoint at handler. Provided it doesn't
	342	# lose its cool, this is not a problem, it just has to note
	343	# that the breakpoint condition is false and keep going.
	344
	345	gdb_test "p func1 ()" "^p func1 \\(\\)\r\n.\[0-9\]* = void" \
	346	"p func1 () #1 in signals.exp"
	347
	348	# Make sure the count got incremented.
	349
	350	# Haven't investigated this xfail
	351	setup_xfail "rs6000--"
5c6f833b	352	setup_xfail "powerpc--"
2f11e8d4	353	gdb_test "p count" "= 2" "p count #1 in signals.exp"
5c6f833b	354	if { [istarget "rs6000--"] \|\| [istarget "powerpc--"] } { return 0 }
2f11e8d4 JL	355
	356	gdb_test "condition \$handler_breakpoint_number" "now unconditional\\."
	357	gdb_test "next" "alarm \\(.*" "next to alarm #2 in signals.exp"
	358	gdb_test "next" "\\+\\+count; /\\* second \\*/" \
	359	"next to ++count #2 in signals.exp"
787f6220	360	sleep 2
2f11e8d4 JL	361
	362	# This time we stop when GDB tries to run the stack dummy.
	363	# So it is OK that we do not print the return value from the function.
	364	gdb_test "p func1 ()" \
	365	"Breakpoint \[0-9\], handler.
	366	The program being debugged stopped while in a function called from GDB.*" \
	367	"p func1 () #2 in signals.exp"
	368	# But we should be able to backtrace...
a26fa899	369	# On alpha-*-osf2.0 this test works when run manually but sometime fails when
8a25c34c	370	# run under dejagnu, making it very hard to debug the problem. Weird...
2f11e8d4 JL	371	gdb_test "bt" "#0.handler.#1.#2.main.*" "bt in signals.exp"
	372	# ...and continue...
	373	gdb_test "continue" "Continuing\\." "continue in signals.exp"
	374	# ...and then count should have been incremented
	375	gdb_test "p count" "= 5" "p count #2 in signals.exp"
	376	}
	377
	378	return 0