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

# Copyright 1997, 1998, 1999, 2003, 2004 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.  

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

	# NOTE: cagney/2004-05-09: The following is retained as an
	# historical reference.  Because signal delivery when doing a
	# next has been changed to use a continue, and not a
	# single-step, the kernel bug of a stuck trace-bit in the
	# trampoline's saved PS register is avoided.

	# 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.

	gdb_test "next" "alarm .*" "next to 2nd alarm"

	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.*signal handler.*#2.* main .*" \
	    "backtrace in signals_tests_1"

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

	# NOTE: cagney/2004-05-09: Ref "next to 2nd alarm" above.
	# Because signal delivery when doing a next has been changed
	# to use a continue, and not a single-step, the kernel bug of
	# a stuck trace-bit in the trampoline's saved PS register is
	# avoided.

	gdb_test "continue" "Breakpoint.*func1.*" "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.*signal handler.*#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