From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Yao Qi <yao@codesourcery.com>
Subject: Re: [patch] Skip kill-after-signal.exp if hw single-step is not supported
Date: Wed, 20 Jul 2011 15:12:00 -0000 [thread overview]
Message-ID: <201107201605.43767.pedro@codesourcery.com> (raw)
In-Reply-To: <4E259815.8080001@codesourcery.com>
On Tuesday 19 July 2011 15:43:33, Yao Qi wrote:
> 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?
>
> --
> Yao (齐尧)
> skip_kill_after_signal.patch
> 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*"] } {
Other archs !x86, and other kernels/stubs/servers !Linux that
can do hardware stepping. If we're going to have a list, invert
the logic of the check, defaulting to running the test, and leaving
out archs were we know software stepping is used. Some targets,
like x86/OpenBSD and MacOS, although can hardware step, can't step
into a handler. I think there are a couple more tests that rely on
stepping into a handler. Maybe a predicate in gdb.exp for that
would be good.
> + # 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
> }
--
Pedro Alves
next prev parent reply other threads:[~2011-07-20 15:06 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 [this message]
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
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=201107201605.43767.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--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