This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]