From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: yao@codesourcery.com
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Skip kill-after-signal.exp if hw single-step is not supported
Date: Sat, 23 Jul 2011 23:28:00 -0000 [thread overview]
Message-ID: <201107232210.p6NMAPQm012108@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <4E259815.8080001@codesourcery.com> (message from Yao Qi on Tue, 19 Jul 2011 22:43:33 +0800)
> Date: Tue, 19 Jul 2011 22:43:33 +0800
> From: Yao Qi <yao@codesourcery.com>
>
> This test `gdb_test "stepi" "\r\nhandler .*"' in kill-after-signal.exp
> performs a single-step, and deliver a signal (SIGUSR1) to inferior.
> Software single step can not do that, because the next instruction
> (start of handler) is unable to be determined.
>
> This patch is to allow running this case only on x86 and x86_64, on
> which hardware single step is supported.
>
> OK?
Certainly not. For one thing you only allow to run this on Linux.
But there are other architectures that that have hardware single step.
And there are Operating Systems that implement software single step in
the kernel where this "problem" should not occur. And even when GDB
does the software single stepping, it should be possible to do this
correctly with appropriate OS support.
Proper approach is probably to XFAIL this for the particular targets
that you're dealing with.
> 2011-07-19 Yao Qi <yao@codesourcery.com>
>
> gdb/testsuite/
> * gdb.base/kill-after-signal.exp: Skip if target doesn't support hardware
> single step.
>
> diff --git a/gdb/testsuite/gdb.base/kill-after-signal.exp b/gdb/testsuite/gdb.base/kill-after-signal.exp
> index eecad2e..df0afe7 100644
> --- a/gdb/testsuite/gdb.base/kill-after-signal.exp
> +++ b/gdb/testsuite/gdb.base/kill-after-signal.exp
> @@ -14,6 +14,17 @@
> # along with this program. If not, see <http://www.gnu.org/licenses/>.
>
> set testfile "kill-after-signal"
> +
> +if { ! [istarget "i?86-*-linux*"]
> + && ! [istarget "x86_64-*-linux*"] } {
> + # skip it if target doesn't support hardware single-step. In following tests,
> + # in "stepi", a signal is delivered along with single-step. In software single
> + # step, gdb is unable to determine the next instruction addresses, because start
> + # of signal handler is one of them.
> + untested ${testfile}.exp
> + return
> +}
> +
> if [prepare_for_testing ${testfile}.exp ${testfile}] {
> return -1
> }
prev parent reply other threads:[~2011-07-23 22:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 14:52 Yao Qi
2011-07-20 15:06 ` Jan Kratochvil
2011-07-20 15:12 ` Pedro Alves
2011-07-24 11:40 ` Mark Kettenis
2011-08-09 14:32 ` Yao Qi
2011-08-09 15:24 ` Matthew Gretton-Dann
2011-08-09 15:50 ` Yao Qi
2011-08-18 4:53 ` ping : " Yao Qi
2011-08-28 14:44 ` Yao Qi
2011-09-14 7:18 ` ping 3: " Yao Qi
2011-09-18 2:42 ` Joel Brobecker
2011-09-18 10:22 ` [committed]: " Yao Qi
2011-07-23 23:28 ` Mark Kettenis [this message]
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=201107232210.p6NMAPQm012108@glazunov.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.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