signals.exp

lwip在ucos上的移植

#   Copyright (C) 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:
# [e-mail]

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