d303a6c766
* infrun.c (check_sigtramp2): Delete function. (handle_inferior_event): When single stepping, and taking a signal, set a breakpoint at the signal return address. Delete redundant calls to check_sigtramp2. (insert_step_resume_breakpoint): New function. (through_sigtramp_breakpoint, handle_inferior_event) (follow_exec, wait_for_inferior, fetch_inferior_event) (currently_stepping, keep_going): Delete most uses of through_sigtramp_breakpoint, not that it should be deleted. (delete_breakpoint_current_contents): Delete function. Index: testsuite/ChangeLog 2004-05-10 Andrew Cagney <cagney@redhat.com> * gdb.base/signals.exp (signal_tests_1): Simplify "continue to func1" and "next to 2nd alarm", kernel bug avoided.
557 lines
21 KiB
Text
557 lines
21 KiB
Text
# Copyright 1997, 1998, 1999, 2003 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
|
|
|
|
# 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
|