Re: [PATCH 6/7] range stepping: test case

[Pedro Alves <palves@redhat.com>]

On 05/15/2013 09:27 AM, Yao Qi wrote:
> On 05/15/2013 02:32 AM, Pedro Alves wrote:
>> I prefer this over the convenience variable hack.  If we ever
>> make range stepping work on a target !remote, we can switch to
>> look at "set debug infrun 1" output or some new "set debug range-step"
>> output.  I didn't understand your stated reason in v2 for
>> switching away from this.  If it was that expect buffer
>> overflows, v3 has a tweak that likely fixes it.
> 
> In our tests, when running tests with a problematic stub supporting range
> stepping, the range stepping of the stub falls back to the single stepping.
> This will generate a huge number of rsp packets, and the gdb.log will blow up
> to several giga-byte.

I see.  Thanks, that's much more detailed info than just saying "it's unsafe".

I'm guessing the huge number of RSP packets comes from that big loop in the
test:

  /* Generate a range that includes a loop, which is time consuming.
     Variable C is used to terminate the loop earlier when GDB
     wants.  */
  for (c = 1, a = 0; a < 65535 && c; a++) {for (b = 0; b < 65535 && c; b++) { d1 = d2 * a / b; d2 = d1 *

We could skip most of the range stepping tests if e.g., the
test that steps the short line FAILs:

  /* A line of source will be generated to a number of
    instructions by compiler.  */
  a = b + c + d * e - a; /* location 1 */

WDYT?

> We use convince variable to avoid this problem.  On the other
> hand, I don't think it is a good idea to peek the GDB internal states by
> checking some rsp packets and personally I prefer the way that GDB is able to expose
> some internal states by some means (command "maint" and convince variables, for example).

I don't like using a convenience variable for this, as those are visible
to the user (show convenience).

"maint" seems better.  But I'm not certain of it.  An issue I have with it
is that from the log you just see the condensed report of what happened
(sent 4 vCont;r, should have been 3), while to diagnose the issue you'll
most likely need to get more info than that ("Okay, what was really sent?
What were the ranges?  Were there signals interrupting the range?  Etc.").  I
have a suspicion we'll end up needing to end up with "set debug infrun 1"
on, and look at that too for some of the trickier cases, and end up with
different number of expected ranges depending on target on some cases.

The actual difference between v1 -> v2 wrt to the RSP packets vs
convenience var was surprisingly smaller than I anticipated.  So how
about we go with RSP first, and see how things go from there?

-- 
Pedro Alves