From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 2/7] Deliver signal in hardware single step
Date: Mon, 11 Apr 2016 14:10:00 -0000 [thread overview]
Message-ID: <570BB039.1060806@redhat.com> (raw)
In-Reply-To: <1458749384-19793-3-git-send-email-yao.qi@linaro.org>
On 03/23/2016 04:09 PM, Yao Qi wrote:
> +++ b/gdb/testsuite/gdb.trace/signal.exp
> @@ -166,7 +166,15 @@ while { $loop } {
>
> for { set i 0 } { $i < [expr 20] } { incr i } {
> if {[info exists tracepoint_hits($i)]} {
> - gdb_assert { $tracepoint_hits($i) == $iterations } \
> - "tracepoint $i hit $iterations times"
> +
> + if { $tracepoint_hits($i) == $iterations } {
> + pass "tracepoint $i hit $iterations times"
> + } elseif { $tracepoint_hits($i) > $iterations } {
> + # GDBserver delivers the signal while stepping over tracepoint,
> + # so it is possible that a tracepoint is collected twice.
> + pass "tracepoint $i hit $iterations times: spurious collection"
I think this will make some test runs print, e.g.:
pass "tracepoint 2 hit 4 times: spurious collection"
while others runs print:
pass "tracepoint 2 hit 4 times"
making test result diffing unstable. If so, I think it should
either be written as:
pass "tracepoint $i hit $iterations times (spurious collection)"
making use of the rule that terminating " (...)" bits don't really
count as test message, or always:
pass "tracepoint $i hit $iterations times"
Otherwise LGTM.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-04-11 14:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 16:10 [PATCH 0/7 V2] Step over instruction branches to itself Yao Qi
2016-03-23 16:10 ` [PATCH 6/7] Resume the inferior with signal rather than stepping over Yao Qi
2016-04-11 15:29 ` Pedro Alves
2016-03-23 16:10 ` [PATCH 5/7] [GDBserver] Don't error in reinsert_raw_breakpoint if bp->inserted Yao Qi
2016-04-11 14:54 ` Pedro Alves
2016-03-23 16:10 ` [PATCH 2/7] Deliver signal in hardware single step Yao Qi
2016-04-11 14:10 ` Pedro Alves [this message]
2016-04-22 10:54 ` Yao Qi
2016-03-23 16:10 ` [PATCH 3/7] Force to insert software single step breakpoint Yao Qi
2016-04-11 14:31 ` Pedro Alves
2016-04-13 16:21 ` Yao Qi
2016-04-19 14:54 ` Yao Qi
2016-04-19 15:17 ` Pedro Alves
2016-04-20 7:50 ` Yao Qi
2016-04-22 16:36 ` Pedro Alves
2016-04-25 8:40 ` Yao Qi
2016-03-23 16:10 ` [PATCH 4/7] Insert breakpoint even when the raw breakpoint is found Yao Qi
2016-04-11 14:41 ` Pedro Alves
2016-04-12 9:04 ` Yao Qi
2016-04-12 9:41 ` Pedro Alves
2016-04-25 8:45 ` Yao Qi
2016-03-23 16:10 ` [PATCH 1/7] New test case gdb.trace/signal.exp Yao Qi
2016-04-08 16:52 ` Pedro Alves
2016-04-11 8:41 ` Yao Qi
2016-04-11 14:04 ` Pedro Alves
2016-04-22 10:53 ` Yao Qi
2016-04-26 12:57 ` Pedro Alves
2016-04-11 14:08 ` Pedro Alves
2016-03-23 16:26 ` [PATCH 7/7] New test case gdb.base/branch-to-self.exp Yao Qi
2016-04-11 15:34 ` Pedro Alves
2016-04-25 8:58 ` Yao Qi
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=570BB039.1060806@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.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