2014-01-01 04:54:24 +01:00
|
|
|
# Copyright 2004-2014 Free Software Foundation, Inc.
|
2004-04-21 19:19:28 +02:00
|
|
|
|
|
|
|
# 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
|
2007-08-23 20:14:19 +02:00
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
2004-04-21 19:19:28 +02:00
|
|
|
# (at your option) any later version.
|
2007-08-23 20:14:19 +02:00
|
|
|
#
|
2004-04-21 19:19:28 +02:00
|
|
|
# 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.
|
2007-08-23 20:14:19 +02:00
|
|
|
#
|
2004-04-21 19:19:28 +02:00
|
|
|
# You should have received a copy of the GNU General Public License
|
2007-08-23 20:14:19 +02:00
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
2004-04-21 19:19:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
# The program sigstep.c creates a very simple backtrace containing one
|
2004-08-25 17:26:19 +02:00
|
|
|
# signal handler and signal trampoline. A flag is set and then the
|
|
|
|
# handler returns. This is repeated at infinitum.
|
2004-04-21 19:19:28 +02:00
|
|
|
|
|
|
|
# This test runs the program up to the signal handler, and then
|
2004-08-25 17:26:19 +02:00
|
|
|
# attempts to step/next out of the handler and back into main.
|
2004-04-21 19:19:28 +02:00
|
|
|
|
|
|
|
if [target_info exists gdb,nosignals] {
|
|
|
|
verbose "Skipping sigstep.exp because of nosignals."
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
|
test suite update - gdb.base/s*
Convert files gdb.base/s*.exp to use standard_output_file et al.
* gdb.base/save-bp.exp, gdb.base/savedregs.exp,
gdb.base/scope.exp, gdb.base/sep.exp, gdb.base/sepsymtab.exp,
gdb.base/set-lang-auto.exp, gdb.base/setshow.exp,
gdb.base/setvar.exp, gdb.base/shlib-call.exp,
gdb.base/shreloc.exp, gdb.base/sigall.exp,
gdb.base/sigaltstack.exp, gdb.base/sigbpt.exp,
gdb.base/sigchld.exp, gdb.base/siginfo-addr.exp,
gdb.base/siginfo-infcall.exp, gdb.base/siginfo-obj.exp,
gdb.base/siginfo.exp, gdb.base/signals.exp, gdb.base/signest.exp,
gdb.base/signull.exp, gdb.base/sigrepeat.exp,
gdb.base/sigstep.exp, gdb.base/sizeof.exp,
gdb.base/skip-solib.exp, gdb.base/so-impl-ld.exp,
gdb.base/solib-display.exp, gdb.base/solib-nodir.exp,
gdb.base/solib-overlap.exp, gdb.base/solib-symbol.exp,
gdb.base/solib-weak.exp, gdb.base/source.exp,
gdb.base/stack-checking.exp, gdb.base/stale-infcall.exp,
gdb.base/stap-probe.exp, gdb.base/start.exp,
gdb.base/step-break.exp, gdb.base/step-bt.exp,
gdb.base/step-line.exp, gdb.base/step-resume-infcall.exp,
gdb.base/step-test.exp, gdb.base/structs.exp,
gdb.base/structs2.exp, gdb.base/structs3.exp,
gdb.base/symbol-without-target_section.exp: Use standard_testfile,
standard_output_file, prepare_for_testing, clean_restart.
2013-06-27 20:58:28 +02:00
|
|
|
standard_testfile
|
|
|
|
|
|
|
|
if {[prepare_for_testing $testfile.exp $testfile $srcfile debug]} {
|
|
|
|
untested $testfile.exp
|
2004-04-21 19:19:28 +02:00
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
gdb_test "display/i \$pc"
|
|
|
|
|
|
|
|
# Advance to main
|
|
|
|
if { ![runto_main] } then {
|
2013-06-07 19:31:09 +02:00
|
|
|
gdb_suppress_tests
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
# Pass all the alarms straight through (but verbosely)
|
|
|
|
# gdb_test "handle SIGALRM print pass nostop"
|
|
|
|
# gdb_test "handle SIGVTALRM print pass nostop"
|
|
|
|
# gdb_test "handle SIGPROF print pass nostop"
|
|
|
|
|
|
|
|
# Run to the signal handler, validate the backtrace.
|
|
|
|
gdb_test "break handler"
|
|
|
|
gdb_test "continue" ".* handler .*" "continue to stepi handler"
|
2010-11-30 18:41:14 +01:00
|
|
|
gdb_test_sequence "bt" "backtrace for nexti" {
|
2004-04-21 19:19:28 +02:00
|
|
|
"\[\r\n\]+.0 \[^\r\n\]* handler "
|
|
|
|
"\[\r\n\]+.1 .signal handler called."
|
2010-11-30 18:41:14 +01:00
|
|
|
"\[\r\n\]+.2 \[^\r\n\]* main "
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
proc advance { i } {
|
2011-03-07 17:03:04 +01:00
|
|
|
global gdb_prompt inferior_exited_re
|
2004-08-25 17:26:19 +02:00
|
|
|
set prefix "$i from handler"
|
2004-04-21 19:19:28 +02:00
|
|
|
|
|
|
|
# Get us back into the handler
|
2004-08-25 17:26:19 +02:00
|
|
|
gdb_test "continue" ".* handler .*" "$prefix; continue to handler"
|
2004-04-21 19:19:28 +02:00
|
|
|
|
2004-08-25 17:26:19 +02:00
|
|
|
set test "$prefix; leave handler"
|
2004-04-21 19:19:28 +02:00
|
|
|
gdb_test_multiple "$i" "${test}" {
|
2006-05-01 18:39:36 +02:00
|
|
|
-re "Could not insert single-step breakpoint.*$gdb_prompt $" {
|
2014-10-28 15:32:51 +01:00
|
|
|
setup_kfail gdb/8841 "sparc*-*-openbsd*"
|
2006-05-01 18:39:36 +02:00
|
|
|
fail "$test (could not insert single-step breakpoint)"
|
|
|
|
}
|
2004-04-21 19:19:28 +02:00
|
|
|
-re "done = 1;.*${gdb_prompt} $" {
|
|
|
|
send_gdb "$i\n"
|
2004-09-02 11:47:38 +02:00
|
|
|
exp_continue -continue_timer
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
|
|
|
-re "\} .. handler .*${gdb_prompt} $" {
|
|
|
|
send_gdb "$i\n"
|
2004-09-02 11:47:38 +02:00
|
|
|
exp_continue -continue_timer
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
2011-03-07 17:03:04 +01:00
|
|
|
-re "$inferior_exited_re normally.*${gdb_prompt} $" {
|
2014-10-28 15:32:51 +01:00
|
|
|
setup_kfail gdb/8744 powerpc-*-*bsd*
|
2004-05-11 18:57:04 +02:00
|
|
|
fail "$test (program exited)"
|
2004-04-23 18:44:25 +02:00
|
|
|
}
|
2004-08-25 17:26:19 +02:00
|
|
|
-re "(while ..done|done = 0).*${gdb_prompt} $" {
|
2004-04-23 18:44:25 +02:00
|
|
|
# After stepping out of a function /r signal-handler, GDB will
|
|
|
|
# advance the inferior until it is at the first instruction of
|
|
|
|
# a code-line. While typically things return to the middle of
|
|
|
|
# the "while..." (and hence GDB advances the inferior to the
|
|
|
|
# "return..." line) it is also possible for the return to land
|
|
|
|
# on the first instruction of "while...". Accept both cases.
|
2004-04-21 19:19:28 +02:00
|
|
|
pass "$test"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
proc advancei { i } {
|
2011-03-07 17:03:04 +01:00
|
|
|
global gdb_prompt inferior_exited_re
|
2004-08-25 17:26:19 +02:00
|
|
|
set prefix "$i from handleri"
|
2004-04-21 19:19:28 +02:00
|
|
|
set program_exited 0
|
|
|
|
|
|
|
|
# Get us back into the handler
|
2004-08-25 17:26:19 +02:00
|
|
|
gdb_test "continue" ".* handler .*" "$prefix; continue to handler"
|
2004-04-21 19:19:28 +02:00
|
|
|
|
2004-08-25 17:26:19 +02:00
|
|
|
set test "$prefix; leave handler"
|
2004-04-21 19:19:28 +02:00
|
|
|
gdb_test_multiple "$i" "${test}" {
|
2004-08-09 15:16:16 +02:00
|
|
|
-re "Cannot insert breakpoint 0.*${gdb_prompt} $" {
|
|
|
|
# Some platforms use a special read-only page for signal
|
|
|
|
# trampolines. We can't set a breakpoint there, and we
|
|
|
|
# don't gracefully fall back to single-stepping.
|
2014-10-28 15:32:51 +01:00
|
|
|
setup_kfail gdb/8841 "i?86-*-linux*"
|
|
|
|
setup_kfail gdb/8841 "*-*-openbsd*"
|
2004-08-09 15:16:16 +02:00
|
|
|
fail "$test (could not set breakpoint)"
|
|
|
|
return
|
|
|
|
}
|
2006-05-01 18:39:36 +02:00
|
|
|
-re "Could not insert single-step breakpoint.*$gdb_prompt $" {
|
2014-10-28 15:32:51 +01:00
|
|
|
setup_kfail gdb/8841 "sparc*-*-openbsd*"
|
2006-05-01 18:39:36 +02:00
|
|
|
fail "$test (could not insert single-step breakpoint)"
|
|
|
|
}
|
2006-12-31 21:01:25 +01:00
|
|
|
-re "Breakpoint \[0-9\]*, handler .*${gdb_prompt} $" {
|
|
|
|
fail "$test (hit breakpoint again)"
|
|
|
|
}
|
2004-04-21 19:19:28 +02:00
|
|
|
-re "done = 1;.*${gdb_prompt} $" {
|
|
|
|
send_gdb "$i\n"
|
2004-09-02 11:47:38 +02:00
|
|
|
exp_continue -continue_timer
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
|
|
|
-re "\} .. handler .*${gdb_prompt} $" {
|
|
|
|
send_gdb "$i\n"
|
2004-09-02 11:47:38 +02:00
|
|
|
exp_continue -continue_timer
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
|
|
|
-re "signal handler called.*${gdb_prompt} $" {
|
|
|
|
pass "$test"
|
|
|
|
}
|
|
|
|
-re "main .*${gdb_prompt} $" {
|
|
|
|
fail "$test (in main)"
|
|
|
|
}
|
2011-03-07 17:03:04 +01:00
|
|
|
-re "$inferior_exited_re normally.*${gdb_prompt} $" {
|
2004-05-11 18:57:04 +02:00
|
|
|
fail "$test (program exited)"
|
|
|
|
set program_exited 1
|
|
|
|
}
|
2004-04-21 19:19:28 +02:00
|
|
|
-re "Make handler return now.*y or n. $" {
|
|
|
|
send_gdb "y\n"
|
2004-09-02 11:47:38 +02:00
|
|
|
exp_continue -continue_timer
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-08-25 17:26:19 +02:00
|
|
|
set test "$prefix; leave signal trampoline"
|
2004-04-21 19:19:28 +02:00
|
|
|
gdb_test_multiple "$i" "${test}" {
|
|
|
|
-re "while .*${gdb_prompt} $" {
|
|
|
|
pass "$test (in main)"
|
|
|
|
}
|
|
|
|
-re "signal handler called.*${gdb_prompt} $" {
|
|
|
|
send_gdb "$i\n"
|
2004-09-02 11:47:38 +02:00
|
|
|
exp_continue -continue_timer
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
|
|
|
-re "return .*${gdb_prompt} $" {
|
|
|
|
fail "$test (stepped)"
|
|
|
|
}
|
|
|
|
-re "Make .*frame return now.*y or n. $" {
|
|
|
|
send_gdb "y\n"
|
2004-09-02 11:47:38 +02:00
|
|
|
exp_continue -continue_timer
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
2011-03-07 17:03:04 +01:00
|
|
|
-re "$inferior_exited_re normally.*${gdb_prompt} $" {
|
2014-10-28 15:32:51 +01:00
|
|
|
kfail gdb/8744 "$test (program exited)"
|
2004-05-11 18:57:04 +02:00
|
|
|
set program_exited 1
|
|
|
|
}
|
2004-04-21 19:19:28 +02:00
|
|
|
-re "The program is not being run.*${gdb_prompt} $" {
|
|
|
|
if { $program_exited } {
|
|
|
|
# Previously kfailed with an exit
|
2004-05-11 18:57:04 +02:00
|
|
|
pass "$test (the program is not being run)"
|
2004-04-21 19:19:28 +02:00
|
|
|
} else {
|
2004-05-11 18:57:04 +02:00
|
|
|
fail "$test (the program is not being run)"
|
2004-04-21 19:19:28 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-08-25 17:26:19 +02:00
|
|
|
# Check that we can step/next our way out of a signal handler.
|
|
|
|
|
2004-04-21 19:19:28 +02:00
|
|
|
advance step
|
|
|
|
advancei stepi
|
|
|
|
|
|
|
|
advance next
|
|
|
|
advancei nexti
|
|
|
|
|
|
|
|
advancei finish
|
|
|
|
advancei return
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test_no_output "set done = 1" "Set done as return will have skipped it"
|
2004-08-25 17:26:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
# Check that we can step/next our way into / over a signal handler.
|
|
|
|
|
|
|
|
# There are at least the following cases: breakpoint @pc VS breakpoint
|
|
|
|
# in handler VS step / next / continue.
|
|
|
|
|
|
|
|
# Use the real-time itimer, as otherwize the process never gets enough
|
|
|
|
# time to expire the timer.
|
|
|
|
|
|
|
|
delete_breakpoints
|
|
|
|
set infinite_loop [gdb_get_line_number {while (!done)}]
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test_no_output "set itimer = itimer_real"
|
2004-08-25 17:26:19 +02:00
|
|
|
gdb_test "break [gdb_get_line_number {done = 0}]"
|
|
|
|
|
|
|
|
# Try stepping when there's a signal pending, and a breakpoint at the
|
|
|
|
# handler. Should step into the signal handler.
|
|
|
|
|
|
|
|
proc skip_to_handler { i } {
|
|
|
|
global gdb_prompt
|
|
|
|
global infinite_loop
|
|
|
|
set prefix "$i to handler"
|
|
|
|
|
|
|
|
# Run around to the done
|
2004-09-23 22:29:30 +02:00
|
|
|
# You can add more patterns to this if you need them.
|
2004-08-25 17:26:19 +02:00
|
|
|
set test "$prefix; resync"
|
|
|
|
gdb_test_multiple "continue" "$test" {
|
|
|
|
-re "done = 0.*$gdb_prompt " {
|
|
|
|
pass "$test"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Advance to the infinite loop
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "advance $infinite_loop" ".*" "$prefix; advance to infinite loop"
|
2004-08-25 17:26:19 +02:00
|
|
|
|
|
|
|
# Make the signal pending
|
|
|
|
sleep 1
|
|
|
|
|
|
|
|
# Insert / remove the handler breakpoint.
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "break handler" ".*" "$prefix; break handler"
|
2004-08-25 17:26:19 +02:00
|
|
|
gdb_test "$i" " handler .*" "$prefix; performing $i"
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "clear handler" ".*" "$prefix; clear handler"
|
2004-08-25 17:26:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
skip_to_handler step
|
|
|
|
skip_to_handler next
|
|
|
|
skip_to_handler continue
|
|
|
|
|
2004-08-31 16:43:18 +02:00
|
|
|
# Try stepping when there's a signal pending, and a breakpoint at the
|
|
|
|
# handler's entry-point. Should step into the signal handler stopping
|
|
|
|
# at the entry-point.
|
|
|
|
|
|
|
|
# Some systems (e.x., GNU/Linux as of 2004-08-30), when delivering a
|
|
|
|
# signal, resume the process at the first instruction of the signal
|
|
|
|
# handler and not the first instruction of the signal trampoline. The
|
|
|
|
# stack is constructed such that the signal handler still appears to
|
|
|
|
# have been called by the trampoline code. This test checks that it
|
|
|
|
# is possible to stop the inferior, even at that first instruction.
|
|
|
|
|
|
|
|
proc skip_to_handler_entry { i } {
|
|
|
|
global gdb_prompt
|
|
|
|
global infinite_loop
|
|
|
|
set prefix "$i to handler entry"
|
|
|
|
|
|
|
|
# Run around to the done
|
2004-09-23 22:29:30 +02:00
|
|
|
# You can add more patterns to this if you need them.
|
2004-08-31 16:43:18 +02:00
|
|
|
set test "$prefix; resync"
|
|
|
|
gdb_test_multiple "continue" "$test" {
|
|
|
|
-re "done = 0.*$gdb_prompt " {
|
|
|
|
pass "$test"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Advance to the infinite loop
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "advance $infinite_loop" ".*" "$prefix; advance to infinite loop"
|
2004-08-31 16:43:18 +02:00
|
|
|
|
|
|
|
# Make the signal pending
|
|
|
|
sleep 1
|
|
|
|
|
|
|
|
# Insert / remove the handler breakpoint.
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "break *handler" ".*" "$prefix; break handler"
|
2004-08-31 16:43:18 +02:00
|
|
|
gdb_test "$i" " handler .*" "$prefix; performing $i"
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "clear *handler" ".*" "$prefix; clear handler"
|
2004-08-31 16:43:18 +02:00
|
|
|
}
|
|
|
|
|
stepi/nexti: skip signal handler if "handle nostop" signal arrives
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.
I was surprised the testsuite doesn't catch this difference. Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.
My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is. I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.
But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped. A user might
well be excused for being confused by this, given:
(gdb) help step
Step program until it reaches a different source line.
And the signal handler's sources will be in different source lines,
after all.
I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.
E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered. For that use case, it'd seem nicer to me if "step" also
stepped into handlers.
This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.
In any case, I think it's simpler (and thus better) for all step
commands to behave the same. This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.
To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler. The change concerns signals that don't cause a stop and
that arrive while the step is in progress.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Also skip handlers when a random
signal arrives while handling a "stepi" or a "nexti". Set the
thread's 'step_after_step_resume_breakpoint' flag.
gdb/doc/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Continuing and Stepping): Add cross reference to
info on stepping and signal handlers.
(Signals): Explain stepping and signal handlers. Add context
index entry, and cross references.
gdb/testsuite/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
|
|
|
foreach cmd {"stepi" "nexti" "step" "next" "continue"} {
|
|
|
|
skip_to_handler_entry $cmd
|
|
|
|
}
|
|
|
|
|
|
|
|
# Get the address of where a single-step should land.
|
|
|
|
|
|
|
|
proc get_next_pc {test} {
|
|
|
|
global gdb_prompt
|
|
|
|
global hex
|
|
|
|
|
|
|
|
set next ""
|
|
|
|
gdb_test_multiple "x/2i \$pc" $test {
|
|
|
|
-re "$hex .*:\[^\r\n\]+\r\n\[ \]+($hex).*\.\r\n$gdb_prompt $" {
|
|
|
|
set next $expect_out(1,string)
|
|
|
|
pass $test
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return $next
|
|
|
|
}
|
|
|
|
|
|
|
|
# Test that the command skipped over the handler.
|
|
|
|
|
|
|
|
proc test_skip_handler {prefix i} {
|
|
|
|
if {$i == "stepi" || $i == "nexti"} {
|
|
|
|
set next_pc [get_next_pc "$prefix; get next PC"]
|
|
|
|
gdb_test "$i" "dummy = 0.*" "$prefix; performing $i"
|
|
|
|
gdb_test "p /x \$pc" " = $next_pc" "$prefix; advanced"
|
|
|
|
} else {
|
|
|
|
gdb_test "$i" "done = 0.*" "$prefix; performing $i"
|
|
|
|
}
|
|
|
|
}
|
2004-08-31 16:43:18 +02:00
|
|
|
|
2004-08-25 17:26:19 +02:00
|
|
|
# Try stepping when there's a signal pending but no breakpoints.
|
|
|
|
# Should skip the handler advancing to the next line.
|
|
|
|
|
|
|
|
proc skip_over_handler { i } {
|
|
|
|
global gdb_prompt
|
|
|
|
global infinite_loop
|
|
|
|
set prefix "$i over handler"
|
|
|
|
|
|
|
|
# Run around to the done
|
2004-09-23 22:29:30 +02:00
|
|
|
# You can add more patterns to this if you need them.
|
2004-08-25 17:26:19 +02:00
|
|
|
set test "$prefix; resync"
|
|
|
|
gdb_test_multiple "continue" "$test" {
|
|
|
|
-re "done = 0.*$gdb_prompt " {
|
|
|
|
pass "$test"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Advance to the infinite loop
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "advance $infinite_loop" ".*" "$prefix; advance to infinite loop"
|
2004-08-25 17:26:19 +02:00
|
|
|
|
|
|
|
# Make the signal pending
|
|
|
|
sleep 1
|
stepi/nexti: skip signal handler if "handle nostop" signal arrives
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.
I was surprised the testsuite doesn't catch this difference. Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.
My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is. I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.
But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped. A user might
well be excused for being confused by this, given:
(gdb) help step
Step program until it reaches a different source line.
And the signal handler's sources will be in different source lines,
after all.
I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.
E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered. For that use case, it'd seem nicer to me if "step" also
stepped into handlers.
This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.
In any case, I think it's simpler (and thus better) for all step
commands to behave the same. This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.
To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler. The change concerns signals that don't cause a stop and
that arrive while the step is in progress.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Also skip handlers when a random
signal arrives while handling a "stepi" or a "nexti". Set the
thread's 'step_after_step_resume_breakpoint' flag.
gdb/doc/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Continuing and Stepping): Add cross reference to
info on stepping and signal handlers.
(Signals): Explain stepping and signal handlers. Add context
index entry, and cross references.
gdb/testsuite/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
|
|
|
|
|
|
|
test_skip_handler $prefix $i
|
2004-08-25 17:26:19 +02:00
|
|
|
}
|
|
|
|
|
stepi/nexti: skip signal handler if "handle nostop" signal arrives
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.
I was surprised the testsuite doesn't catch this difference. Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.
My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is. I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.
But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped. A user might
well be excused for being confused by this, given:
(gdb) help step
Step program until it reaches a different source line.
And the signal handler's sources will be in different source lines,
after all.
I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.
E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered. For that use case, it'd seem nicer to me if "step" also
stepped into handlers.
This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.
In any case, I think it's simpler (and thus better) for all step
commands to behave the same. This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.
To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler. The change concerns signals that don't cause a stop and
that arrive while the step is in progress.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Also skip handlers when a random
signal arrives while handling a "stepi" or a "nexti". Set the
thread's 'step_after_step_resume_breakpoint' flag.
gdb/doc/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Continuing and Stepping): Add cross reference to
info on stepping and signal handlers.
(Signals): Explain stepping and signal handlers. Add context
index entry, and cross references.
gdb/testsuite/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
|
|
|
foreach cmd {"stepi" "nexti" "step" "next" "continue"} {
|
|
|
|
skip_over_handler $cmd
|
|
|
|
}
|
2004-08-25 17:26:19 +02:00
|
|
|
|
|
|
|
# Try stepping when there's a signal pending, a pre-existing
|
|
|
|
# breakpoint at the current instruction, and a breakpoint in the
|
|
|
|
# handler. Should advance to the signal handler.
|
|
|
|
|
|
|
|
proc breakpoint_to_handler { i } {
|
|
|
|
global gdb_prompt
|
|
|
|
global infinite_loop
|
|
|
|
set prefix "$i on breakpoint, to handler"
|
|
|
|
|
|
|
|
# Run around to the done
|
2004-09-23 22:29:30 +02:00
|
|
|
# You can add more patterns to this if you need them.
|
2004-08-25 17:26:19 +02:00
|
|
|
set test "$prefix; resync"
|
|
|
|
gdb_test_multiple "continue" "$test" {
|
|
|
|
-re "done = 0.*$gdb_prompt " {
|
|
|
|
pass "$test"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "break $infinite_loop" ".*" "$prefix; break infinite loop"
|
|
|
|
gdb_test "break handler" ".*" "$prefix; break handler"
|
2004-08-25 17:26:19 +02:00
|
|
|
|
|
|
|
# Continue to the infinite loop
|
|
|
|
gdb_test "continue" "while ..done.*" "$prefix; continue to infinite loop"
|
|
|
|
|
|
|
|
# Make the signal pending
|
|
|
|
sleep 1
|
|
|
|
|
|
|
|
gdb_test "$i" " handler .*" "$prefix; performing $i"
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "clear $infinite_loop" ".*" "$prefix; clear infinite loop"
|
|
|
|
gdb_test "clear handler" ".*" "$prefix; clear handler"
|
2004-08-25 17:26:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
breakpoint_to_handler step
|
|
|
|
breakpoint_to_handler next
|
|
|
|
breakpoint_to_handler continue
|
|
|
|
|
2004-08-31 16:43:18 +02:00
|
|
|
# Try stepping when there's a signal pending, and a breakpoint at the
|
|
|
|
# handler's entry instruction and a breakpoint at the current
|
|
|
|
# instruction. Should step into the signal handler and breakpoint at
|
|
|
|
# that entry instruction.
|
|
|
|
|
|
|
|
# Some systems (e.x., GNU/Linux as of 2004-08-30), when delivering a
|
|
|
|
# signal, resume the process at the first instruction of the signal
|
|
|
|
# handler and not the first instruction of the signal trampoline. The
|
|
|
|
# stack is constructed such that the signal handler still appears to
|
|
|
|
# have been called by the trampoline code. This test checks that it
|
|
|
|
# is possible to stop the inferior, even at that first instruction.
|
|
|
|
|
|
|
|
proc breakpoint_to_handler_entry { i } {
|
|
|
|
global gdb_prompt
|
|
|
|
global infinite_loop
|
|
|
|
set prefix "$i on breakpoint, to handler entry"
|
|
|
|
|
|
|
|
# Run around to the done
|
2004-09-23 22:29:30 +02:00
|
|
|
# You can add more patterns to this if you need them.
|
2004-08-31 16:43:18 +02:00
|
|
|
set test "$prefix; resync"
|
|
|
|
gdb_test_multiple "continue" "$test" {
|
|
|
|
-re "done = 0.*$gdb_prompt " {
|
|
|
|
pass "$test"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "break $infinite_loop" ".*" "$prefix; break infinite loop"
|
|
|
|
gdb_test "break *handler" ".*" "$prefix; break handler"
|
2004-08-31 16:43:18 +02:00
|
|
|
|
|
|
|
# Continue to the infinite loop
|
|
|
|
gdb_test "continue" "while ..done.*" "$prefix; continue to infinite loop"
|
|
|
|
|
|
|
|
# Make the signal pending
|
|
|
|
sleep 1
|
|
|
|
|
|
|
|
gdb_test "$i" " handler .*" "$prefix; performing $i"
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "clear $infinite_loop" ".*" "$prefix; clear infinite loop"
|
|
|
|
gdb_test "clear *handler" ".*" "$prefix; clear handler"
|
2004-08-31 16:43:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
breakpoint_to_handler_entry step
|
|
|
|
breakpoint_to_handler_entry next
|
|
|
|
breakpoint_to_handler_entry continue
|
|
|
|
|
2004-08-25 17:26:19 +02:00
|
|
|
# Try stepping when there's a signal pending, and a pre-existing
|
|
|
|
# breakpoint at the current instruction, and no breakpoint in the
|
stepi/nexti: skip signal handler if "handle nostop" signal arrives
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.
I was surprised the testsuite doesn't catch this difference. Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.
My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is. I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.
But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped. A user might
well be excused for being confused by this, given:
(gdb) help step
Step program until it reaches a different source line.
And the signal handler's sources will be in different source lines,
after all.
I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.
E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered. For that use case, it'd seem nicer to me if "step" also
stepped into handlers.
This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.
In any case, I think it's simpler (and thus better) for all step
commands to behave the same. This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.
To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler. The change concerns signals that don't cause a stop and
that arrive while the step is in progress.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Also skip handlers when a random
signal arrives while handling a "stepi" or a "nexti". Set the
thread's 'step_after_step_resume_breakpoint' flag.
gdb/doc/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Continuing and Stepping): Add cross reference to
info on stepping and signal handlers.
(Signals): Explain stepping and signal handlers. Add context
index entry, and cross references.
gdb/testsuite/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
|
|
|
# handler. Should advance to the next line/instruction.
|
2004-08-25 17:26:19 +02:00
|
|
|
|
|
|
|
proc breakpoint_over_handler { i } {
|
|
|
|
global gdb_prompt
|
|
|
|
global infinite_loop
|
|
|
|
set prefix "$i on breakpoint, skip handler"
|
|
|
|
|
|
|
|
# Run around to the done
|
2004-09-23 22:29:30 +02:00
|
|
|
# You can add more patterns to this if you need them.
|
2004-08-25 17:26:19 +02:00
|
|
|
set test "$prefix; resync"
|
|
|
|
gdb_test_multiple "continue" "$test" {
|
|
|
|
-re "done = 0.*$gdb_prompt " {
|
|
|
|
pass "$test"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "break $infinite_loop" ".*" "$prefix; break infinite loop"
|
2004-08-25 17:26:19 +02:00
|
|
|
|
|
|
|
# Continue to the infinite loop
|
|
|
|
gdb_test "continue" "while ..done.*" "$prefix; continue to infinite loop"
|
|
|
|
|
|
|
|
# Make the signal pending
|
|
|
|
sleep 1
|
|
|
|
|
stepi/nexti: skip signal handler if "handle nostop" signal arrives
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.
I was surprised the testsuite doesn't catch this difference. Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.
My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is. I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.
But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped. A user might
well be excused for being confused by this, given:
(gdb) help step
Step program until it reaches a different source line.
And the signal handler's sources will be in different source lines,
after all.
I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.
E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered. For that use case, it'd seem nicer to me if "step" also
stepped into handlers.
This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.
In any case, I think it's simpler (and thus better) for all step
commands to behave the same. This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.
To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler. The change concerns signals that don't cause a stop and
that arrive while the step is in progress.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Also skip handlers when a random
signal arrives while handling a "stepi" or a "nexti". Set the
thread's 'step_after_step_resume_breakpoint' flag.
gdb/doc/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Continuing and Stepping): Add cross reference to
info on stepping and signal handlers.
(Signals): Explain stepping and signal handlers. Add context
index entry, and cross references.
gdb/testsuite/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
|
|
|
test_skip_handler $prefix $i
|
2010-06-01 23:29:21 +02:00
|
|
|
gdb_test "clear $infinite_loop" ".*" "$prefix; clear infinite loop"
|
2004-08-25 17:26:19 +02:00
|
|
|
}
|
|
|
|
|
stepi/nexti: skip signal handler if "handle nostop" signal arrives
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.
I was surprised the testsuite doesn't catch this difference. Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.
My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is. I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.
But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped. A user might
well be excused for being confused by this, given:
(gdb) help step
Step program until it reaches a different source line.
And the signal handler's sources will be in different source lines,
after all.
I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.
E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered. For that use case, it'd seem nicer to me if "step" also
stepped into handlers.
This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.
In any case, I think it's simpler (and thus better) for all step
commands to behave the same. This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.
To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler. The change concerns signals that don't cause a stop and
that arrive while the step is in progress.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Also skip handlers when a random
signal arrives while handling a "stepi" or a "nexti". Set the
thread's 'step_after_step_resume_breakpoint' flag.
gdb/doc/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Continuing and Stepping): Add cross reference to
info on stepping and signal handlers.
(Signals): Explain stepping and signal handlers. Add context
index entry, and cross references.
gdb/testsuite/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
|
|
|
foreach cmd {"stepi" "nexti" "step" "next" "continue"} {
|
|
|
|
breakpoint_over_handler $cmd
|
|
|
|
}
|