Re: [PATCH 5/5] range stepping: tests

[Yao Qi <yao at codesourcery dot com>]

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