Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: Pedro Alves <palves@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 5/5] range stepping: tests
Date: Wed, 22 May 2013 14:32:00 -0000	[thread overview]
Message-ID: <519CD71E.1060402@codesourcery.com> (raw)
In-Reply-To: <20130514191102.13213.74060.stgit@brno.lan>

On 05/15/2013 03:11 AM, Pedro Alves wrote:

Pedro,
the tests look good to me overall.  Some nits below,

> +
> +  /* Generate a range that includes a loop in it.  */

Nit: "a range" is not clear, and we should mention that they must
belong to a single line of source.  How about this?

  Generate a range of instructions compiled from a single line of
source that include a loop.

> +#define RANGE_WITH_LOOP	\
> +  do								\
> +    {								\
> +      for (a = 0, e = 0; a < 15; a++)				\
> +	e += a;							\
> +    } while (0)
> +
> +  RANGE_WITH_LOOP;
> +
> +  RANGE_WITH_LOOP;
> +
> +  /* Generate a range that includes a time-consuming loop.  GDB breaks
> +     the loop early by clearing variable 'c'.  */

Likewise.

> +
> +with_test_prefix "step over func" {
> +
> +    set line_num [gdb_get_line_number "location 2"]
> +    gdb_test "where" "main \\(\\) at .*${srcfile}:${line_num}.*"
> +
> +    # It's expected to get three stops and two 'vCont;r's.  In the C
> +    # code, the line of C source produces roughly the following
> +    # instructions:
> +    #
> +    # addr1:
> +    #  insn1
> +    #  insn2
> +    #  ...
> +    #  call func1
> +    # addr2:
> +    #  ...
> +    #  insn3
> +    # addr3:
> +    #  insn4
> +    #
> +    # Something like this will happen:
> +    # --> vCont;rADDR1,ADDR3  (range step from ADDR1 to ADDR3)
> +    # <-- T05  (target single-stepped to func, which is out of the step range)
> +    # --> $Z0,ADDR2  (place step-resume breakpoint at ADDR2)
> +    # --> vCont;c  (resume)
> +    # <-- T05  (target stops at ADDR2)
> +    # --> vCont;rADDR1,ADDR3  (continues range stepping)
> +    # <-- T05
> +    exec_cmd_expect_vCont_count "next" 0 2
> +}
> +
> +# Check that breapoints interrupt range stepping correctly.
                breakpoints

> +
> +  /* Generate a single-range line with a label in the middle where we
                   ^^^^^^^^^^^^^^^^^
How about "a single line"?

> +
> +# Check that range stepping works well with tracepoints.
> +
> +proc range_stepping_with_tracepoint { type } {
> +    with_test_prefix "${type}" {
> +	gdb_breakpoint [gdb_get_line_number "location 1"]
> +	gdb_continue_to_breakpoint "location 1"
> +	delete_breakpoints
> +
> +	gdb_test "${type} *set_point" ".*"
> +	gdb_test_no_output "tstart"
> +
> +	# Step a line with a tracepoint in the middle.  The tracepoint
> +	# itself shouldn't have any effect on range stepping.  We
> +	# should see one vCont;r and no vCont;s's.
                                        ^^^^^^^^^
"vCont;s", singular form?

The patch below is to skip the rest of range stepping tests if the
first one fails, to avoid the issue of huge number of rsp packets in
gdb.log.  It is on top of your series.  It works well with my stub.

I've run out of time today, and I'll have a look at the rest of
this series tomorrow.

-- 
Yao (齐尧)

gdb/testsuite:

2013-05-22  Yao Qi  <yao@codesourcery.com>

	* gdb.base/range-stepping.exp: Skip the rest of tests if test
	fails.
---
 gdb/testsuite/gdb.base/range-stepping.exp |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/gdb/testsuite/gdb.base/range-stepping.exp b/gdb/testsuite/gdb.base/range-stepping.exp
index def25ce..aa5d34f 100644
--- a/gdb/testsuite/gdb.base/range-stepping.exp
+++ b/gdb/testsuite/gdb.base/range-stepping.exp
@@ -85,6 +85,14 @@ with_test_prefix "multi insns" {
 	    set pc_after_stepping $expect_out(1,string)
 	    pass $msg
 	}
+	-re ".*" {
+	    fail $msg
+	    # It is the first test on range-stepping, and the simplest
+	    # one.  If it fails, probably the rest of the tests fail
+	    # and huge number of rsp packets will blow up the gdb.log
+	    # file.  Skip the rest of the tests.
+	    return
+	}
     }
 
     # There should be at least two instructions between
-- 
1.7.7.6


  reply	other threads:[~2013-05-22 14:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-14 19:10 [PATCH 0/5 V3] target-assisted range stepping Pedro Alves
2013-05-14 19:10 ` [PATCH 4/5] range stepping: gdbserver (x86 GNU/Linux) Pedro Alves
2013-05-14 19:47   ` Eli Zaretskii
2013-05-14 20:14   ` Tom Tromey
2013-05-23 17:44     ` Pedro Alves
2013-05-24 11:33       ` Pedro Alves
2013-05-15 12:14   ` Yao Qi
2013-05-20 18:01     ` Pedro Alves
2013-05-23  0:56   ` Yao Qi
2013-05-23 17:26     ` Pedro Alves
2013-05-14 19:10 ` [PATCH 2/5] Convert rs->support_vCont_t to a struct Pedro Alves
2013-05-14 19:40   ` Tom Tromey
2013-05-14 19:10 ` [PATCH 1/5] Factor out in-stepping-range checks Pedro Alves
2013-05-14 19:37   ` Tom Tromey
2013-05-14 19:10 ` [PATCH 3/5] range stepping: gdb Pedro Alves
2013-05-14 19:46   ` Eli Zaretskii
2013-05-15 10:23     ` Pedro Alves
2013-05-15 11:22       ` Eli Zaretskii
2013-05-15 12:39         ` Pedro Alves
2013-05-15 13:46           ` Eli Zaretskii
2013-05-15 13:58             ` Pedro Alves
2013-05-15 18:20               ` Pedro Alves
2013-05-16  6:08                 ` Eli Zaretskii
2013-05-20 18:43                   ` Pedro Alves
2013-05-20 19:05                     ` Eli Zaretskii
2013-05-23  0:47                     ` Yao Qi
2013-05-23 17:22                       ` Pedro Alves
2013-05-14 19:11 ` [PATCH 5/5] range stepping: tests Pedro Alves
2013-05-22 14:32   ` Yao Qi [this message]
2013-05-23 17:34     ` Pedro Alves
2013-05-23 18:03     ` Pedro Alves
2013-05-24  2:27       ` Yao Qi
2013-05-24  9:45         ` Pedro Alves
2013-05-24  9:57           ` Yao Qi
2013-05-14 20:21 ` [PATCH 0/5 V3] target-assisted range stepping Tom Tromey
2013-05-23 17:44   ` Pedro Alves
2013-05-23  1:02 ` Yao Qi
2013-05-23 17:46   ` Pedro Alves

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=519CD71E.1060402@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@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