From: Andrew Cagney <cagney@gnu.org>
To: gdb-patches@sources.redhat.com
Subject: [rfa/testsuite] Signals vs handler entry-point
Date: Mon, 30 Aug 2004 17:44:00 -0000 [thread overview]
Message-ID: <41336710.2050801@gnu.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Hello,
On GNU/Linux systems, when deliverying a signal, the process is resumed
at the first instruction of the handler, and not the first instruction
of the signal trampoline. This checks that a breakpoint on that first
handler instruction still works.
Tested on a i386 GNU/Linux, it 1738 kfailed when single-stepping.
Tested on a patched PPC/NetBSD, it passed (doesn't have that feature).
Ok?
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 4123 bytes --]
Index: ChangeLog
2004-08-30 Andrew Cagney <cagney@gnu.org>
* gdb.base/sigstep.exp (breakpoint_to_handler_entry)
(skip_to_handler_entry): New procedures. Test stepping into a
handler when the breakpoint is at the handler's entry point.
Index: gdb.base/sigstep.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/sigstep.exp,v
retrieving revision 1.6
diff -p -u -r1.6 sigstep.exp
--- gdb.base/sigstep.exp 30 Aug 2004 16:59:45 -0000 1.6
+++ gdb.base/sigstep.exp 30 Aug 2004 17:37:42 -0000
@@ -235,6 +235,47 @@ skip_to_handler step
skip_to_handler next
skip_to_handler continue
+# 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
+ set test "$prefix; resync"
+ gdb_test_multiple "continue" "$test" {
+ -re "done = 0.*$gdb_prompt " {
+ pass "$test"
+ }
+ # other patterns can go here
+ }
+
+ # Advance to the infinite loop
+ gdb_test "advance $infinite_loop" "" "$prefix; advance to infinite loop"
+
+ # Make the signal pending
+ sleep 1
+
+ # Insert / remove the handler breakpoint.
+ gdb_test "break *handler" "" "$prefix; break handler"
+ gdb_test "$i" " handler .*" "$prefix; performing $i"
+ gdb_test "clear *handler" "" "$prefix; clear handler"
+}
+
+skip_to_handler_entry step
+skip_to_handler_entry next
+skip_to_handler_entry continue
+
# Try stepping when there's a signal pending but no breakpoints.
# Should skip the handler advancing to the next line.
@@ -302,6 +343,51 @@ breakpoint_to_handler step
breakpoint_to_handler next
breakpoint_to_handler continue
+# 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
+ set test "$prefix; resync"
+ gdb_test_multiple "continue" "$test" {
+ -re "done = 0.*$gdb_prompt " {
+ pass "$test"
+ }
+ # other patterns can go here
+ }
+
+ gdb_test "break $infinite_loop" "" "$prefix; break infinite loop"
+ gdb_test "break *handler" "" "$prefix; break handler"
+
+ # Continue to the infinite loop
+ gdb_test "continue" "while ..done.*" "$prefix; continue to infinite loop"
+
+ # Make the signal pending
+ sleep 1
+
+ setup_kfail "i*86-*-*" gdb/1738
+ gdb_test "$i" " handler .*" "$prefix; performing $i"
+ gdb_test "clear $infinite_loop" "" "$prefix; clear infinite loop"
+ gdb_test "clear *handler" "" "$prefix; clear handler"
+}
+
+breakpoint_to_handler_entry step
+breakpoint_to_handler_entry next
+breakpoint_to_handler_entry continue
+
# Try stepping when there's a signal pending, and a pre-existing
# breakpoint at the current instruction, and no breakpoint in the
# handler. Should advance to the next line.
next reply other threads:[~2004-08-30 17:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-30 17:44 Andrew Cagney [this message]
2004-08-30 18:06 ` Michael Chastain
2004-08-31 14:44 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41336710.2050801@gnu.org \
--to=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox