+if $nosignals {
+ verbose "Skipping signals.exp because of nosignals."
+ continue
+ }
+
if $tracelevel then {
strace $tracelevel
}
set prms_id 0
set bug_id 0
-set binfile $objdir/$subdir/signals
+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
+}
-if ![file exists $binfile] then {
- perror "$binfile does not exist."
- return 0
+# 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 {
+ if [runto_main] then {
gdb_test "next" "signal \\(SIGUSR1.*" \
"next over signal (SIGALRM, handler)"
gdb_test "next" "alarm \\(.*" \
gdb_test "next" "\\+\\+count; /\\* first \\*/" \
"next over alarm (1)"
# An alarm has been signaled, give the signal time to get delivered.
- exec sleep 2
+ sleep 2
# i386 BSD currently fails the next test with a SIGTRAP.
setup_xfail "i*86-*-bsd*"
clear_xfail "i*86-sequent-bsd*"
# Univel SVR4 i386 continues instead of stepping.
setup_xfail "i*86-univel-sysv4*"
- send "next\n"
+ # 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 $" {
# Solaris is not a relevant data point either way
# because it lacks single stepping.
- fail "'next' behaved as 'continue'"
+ # 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)" }
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.
- exec sleep 2
+ sleep 2
set bash_bug 0
- send "next\n"
+ send_gdb "next\n"
+ setup_xfail "i*86-pc-linux-gnu"
expect {
-re "Breakpoint.*handler.*$prompt $" {
pass "next to handler in signals_tests_1"
# 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"
# a SIGTRAP, but with different symptoms.
setup_xfail "vax-*-ultrix*"
setup_xfail "i*86-*-bsd*"
- send "continue\n"
+ 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 $" {
}
setup_xfail "*-*-irix*"
- send "signal SIGUSR1\n"
+ send_gdb "signal SIGUSR1\n"
expect {
-re "Breakpoint.*handler.*$prompt $" { pass "signal SIGUSR1" }
-re "Program received signal SIGUSR1.*$prompt $" {
# anytime soon.
setup_xfail "*-*-*"
- send "continue\n"
+ send_gdb "continue\n"
expect {
-re "Breakpoint.*func2.*$prompt $" { pass "continue to func2" }
-re "Breakpoint.*func1.*$prompt $" {
- fail "continue func2"
+ fail "continue to func2"
gdb_test "continue" "Breakpoint.*func2.*" \
"extra continue to func2"
}
default { fail "continue to func2" }
}
- exec sleep 2
+ sleep 2
# GDB yanks out the breakpoints to step over the breakpoint it
# stopped at, which means the breakpoint at handler is yanked.
# 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 "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.
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
# 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 "p 1+1\n"
+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 {
+if [runto_main] then {
gdb_test "break handler if 0" "Breakpoint \[0-9\]+ .*"
gdb_test "set \$handler_breakpoint_number = \$bpnum" ""
gdb_test "next" "\\+\\+count; /\\* first \\*/" \
"next to ++count #1 in signals.exp"
# Give the signal time to get delivered
- exec sleep 2
+ 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
# 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-*-*"] { return 0 }
+ 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"
- exec sleep 2
+ 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.
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"
projects / binutils.git / blobdiff