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

[Yao Qi <yao@codesourcery.com>]

On 05/21/2013 02:28 AM, Pedro Alves wrote:
> 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?

Pedro,
That is a good idea.  It works for my internal stub!  I'll post a delta 
patch on top of yours.

>
>> >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?

I agree.

-- 
Yao (齐尧)