From 98f6da4f021216e9c0fb72eea732e25002bcbad9 Mon Sep 17 00:00:00 2001 From: "J.T. Conklin" Date: Mon, 18 Jul 1994 22:27:07 +0000 Subject: [PATCH] * gdb.base/{a2-run,callfuncs,funcargs,interrupt,mips_pro,nodebug, return,signals,twice}.exp: Handle non-existant binaries consistantly. --- gdb/testsuite/ChangeLog | 4 + gdb/testsuite/gdb.base/funcargs.exp | 14 +- gdb/testsuite/gdb.base/signals.exp | 283 ++++++++++++++++++++++++++++++++++++ 3 files changed, 289 insertions(+), 12 deletions(-) create mode 100644 gdb/testsuite/gdb.base/signals.exp diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index 2a18cc8..94d3ef0 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,5 +1,9 @@ Mon Jul 18 12:18:07 1994 J.T. Conklin (jtc@phishhead.cygnus.com) + * gdb.base/{a2-run,callfuncs,funcargs,interrupt,mips_pro,nodebug, + return,signals,twice}.exp: Handle non-existant binaries + consistantly. + * gdb.base/corefile.exp: Execute coremaker to generate core dump. * gdb.base/Makefile.in: Don't try to generate a core dump, we might testing a cross development system. diff --git a/gdb/testsuite/gdb.base/funcargs.exp b/gdb/testsuite/gdb.base/funcargs.exp index e5f4a43..36236fd 100644 --- a/gdb/testsuite/gdb.base/funcargs.exp +++ b/gdb/testsuite/gdb.base/funcargs.exp @@ -1,4 +1,4 @@ -# Copyright (C) 1992 Free Software Foundation, Inc. +# Copyright (C) 1992, 1994 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 @@ -31,7 +31,7 @@ set srcfile $binfile.c if ![file exists $objdir/$subdir/$binfile] then { perror "$objdir/$subdir/$binfile does not exist." - continue + return 0 } # @@ -1304,11 +1304,6 @@ proc funcargs_reload { } { global binfile global srcdir - if [istarget "a29k-*-udi"] then { - # FIXME: If PR 2415 is fixed, this is not needed. - gdb_target_udi - gdb_load $objdir/$subdir/$binfile - } if [istarget "mips-idt-*"] then { # Restart because IDT/SIM runs out of file descriptors. gdb_exit @@ -1501,9 +1496,4 @@ localvars_in_indirect_call funcargs_reload test_stepping_over_trampolines -if [istarget "a29k-*-udi"] then { - # FIXME: If PR 2415 is fixed, this is not needed. - gdb_target_udi -} - catch "set timeout $oldtimeout" diff --git a/gdb/testsuite/gdb.base/signals.exp b/gdb/testsuite/gdb.base/signals.exp new file mode 100644 index 0000000..0bd0914 --- /dev/null +++ b/gdb/testsuite/gdb.base/signals.exp @@ -0,0 +1,283 @@ +if $tracelevel then { + strace $tracelevel +} + +set prms_id 0 +set bug_id 0 + +gdb_reinitialize_dir $srcdir/$subdir +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" \ + "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" "next to 2nd ++count" + # 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" } + -re "Program received signal SIGEMT.*$prompt $" { + # Bash versions before 1.13.5 cause this behaviour + # by blocking SIGTRAP. + fail "next (known problem with bash versions before 1.13.5)" + set bash_bug 1 + gdb_test "signal 0" "Breakpoint.*handler" + } + -re ".*$prompt $" { fail "next" } + timeout { fail "(timeout)" } + eof { fail "(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" + + 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" } + -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 (probably kernel bug)" + gdb_test "continue" "Breakpoint.*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 (probably kernel bug)" + gdb_test "continue" "Breakpoint.*func1" + } + -re ".*$prompt $" { fail "continue" } + default { fail "continue" } + } + gdb_test "signal SIGUSR1" "Breakpoint.*handler" + + # 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" } + -re "Breakpoint.*func1.*$prompt $" { + fail "continue" + gdb_test "continue" "Breakpoint.*func2" + } + -re ".*$prompt $" { fail "continue" } + default { fail "continue" } + } + + 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" + + # 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" + } +} + +# 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_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" + gdb_test "next" "alarm \[(\]+" + gdb_test "next" "\[+\]+count" + # 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" + + # Make sure the count got incremented. + + # Haven't investigated this xfail + setup_xfail "rs6000-*-*" + gdb_test "p count" "= 2" + if [istarget "rs6000-*-*"] { return 0 } + + gdb_test "condition \\\$handler_breakpoint_number" "now unconditional" + gdb_test "next" "alarm \[(\]+" + gdb_test "next" "\[+\]+count" + 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" + # But we should be able to backtrace... + gdb_test "bt" "#0.*handler.*#1.*#2.*main" + # ...and continue... + gdb_test "continue" "Continuing" + # ...and then count should have been incremented + gdb_test "p count" "= 5" + } +} +return 0 -- 2.7.4