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

Yao Qi
2013-05-22T14:01:59Z

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 (é½å°§)