c86bd3d41b
runto_main is a proc in gdb.exp that will do 'step' for target use
stubs.
* gdb.base/exprs.exp: ditto.
* gdb.base/interrupt.exp: ditto.
* gdb.base/opaque.exp: ditto.
* gdb.base/printcmds.exp: ditto.
* gdb.base/ptype.exp: ditto.
* gdb.base/scope.exp: ditto.
* gdb.base/setvar.exp: ditto.
* gdb.base/signals.exp: ditto.
* gdb.base/twice.exp: ditto.
* gdb.base/break.exp: no run and hit main for stubs. Change line
numbers for breakpoints and info breakpoint.
* gdb.base/break.c: Add #ifdef usestubs for set_debug_traps() and
breakpoint().
* gdb.base/callfuncs.c: ditto.
* gdb.base/exprs: ditto.
* gdb.base/interrupt.c: ditto.
* gdb.base/opaque0.c: ditto.
* gdb.base/printcmds.c: ditto.
* gdb.base/ptype.c: ditto.
* gdb.base/scope0.c: ditto.
* gdb.base/setvar.c: ditto.
* gdb.base/signals.c: ditto.
* gdb.base/twice.c: ditto.
317 lines
11 KiB
Text
317 lines
11 KiB
Text
if $tracelevel then {
|
|
strace $tracelevel
|
|
}
|
|
|
|
set prms_id 0
|
|
set bug_id 0
|
|
|
|
set binfile $objdir/$subdir/signals
|
|
|
|
if ![file exists $binfile] then {
|
|
perror "$binfile does not exist."
|
|
return 0
|
|
}
|
|
|
|
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.
|
|
exec 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*"
|
|
send "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.
|
|
|
|
fail "'next' behaved as 'continue'"
|
|
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.
|
|
exec sleep 2
|
|
|
|
set bash_bug 0
|
|
send "next\n"
|
|
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).
|
|
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*"
|
|
send "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 "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 "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" }
|
|
}
|
|
|
|
exec 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-*-*"
|
|
|
|
# A faulty bash will not step the inferior into sigtramp on sun3.
|
|
if {$bash_bug} then {
|
|
setup_xfail "m68*-*-sunos4*"
|
|
}
|
|
|
|
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
|
|
}
|
|
|
|
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.
|
|
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"
|
|
|
|
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 "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
|
|
exec 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-*-*"
|
|
gdb_test "p count" "= 2" "p count #1 in signals.exp"
|
|
if [istarget "rs6000-*-*"] { 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
|
|
|
|
# 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...
|
|
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
|