Re: [PATCH 3/5] range stepping: gdb

[Pedro Alves <palves@redhat.com>]

On 05/15/2013 02:58 PM, Pedro Alves wrote:
> On 05/15/2013 02:46 PM, Eli Zaretskii wrote:
>>> Date: Wed, 15 May 2013 13:39:05 +0100
>>> From: Pedro Alves <palves@redhat.com>
>>> CC: gdb-patches@sourceware.org
>>>
>>>> Doesn't this mean that these two use cases are explicit exceptions
>>>> from the rule that END is excluded? 
>>>
>>> Nope.  There's no exception.
>>>
>>> With:
>>>
>>>   vCont ;r START,END
>>>
>>>  #1 - The stub single-steps the thread.
>>>  #2 - Once the thread stops, the stub checks whether the thread
>>>       stopped in the [START,END) range.  If so, goto #1.
>>>       It not, goto #3.
>>>  #3 - The stub reports to gdb that the thread stopped stepping.
>>>
>>> If it happens that START and END are the same, then #2 always
>>> goes to #3.
>>
>> I'm simulating a naive reader, while you are replying to someone you
>> consider an experienced code developer ;-)  So we are talking past
>> each other.
> 
> :-)
> 
>> When you say "END is the address of the first instruction beyond the
>> step range", that means, simply put, that execution will always stop
>> before it executes the instruction at END.  IOW, the instruction at
>> END will _not_ be executed.  With that interpretation, a range
>> [START,START) is _empty_ and will never execute any instructions at
>> all.
>>
>> It is OK to use a different interpretation, but then we should either
>> (a) describe the semantics differently to begin with, or (b) explain
>> that [START,START) is an exception.  You seem to object to (b), which
>> then brings us back at (a), meaning that this text:
>>
>>> +@var{end} is the address of the first instruction beyond the step
>>> +range, and @strong{not} the address of the last instruction within it.
>>
>> needs to be reworded, so as not to say that END is _beyond_ the range.
> 
> I see what you mean now.
> 
>> If you want a specific response for the algorithm you show above, then
>> I would ask why does GDB single-step the stub at all, when START and
>> END are equal?  The fact that we implemented this is a 'do-until' loop
>> rather than a 'while' loop, i.e. test at the end instead of at the
>> beginning, is an important implementation detail which must be present
>> explicitly in the description of what this feature does.  
> 
> I agree.  This is the sort of detail I could see different stubs
> ending up implementing differently, so I wanted to be sure it
> was clearly specified.  Well, clearly I failed.  :-)
> 
>> The very need you felt to explain this is already a clear sign that
>> the original description is wrong.
> 
> I'll try to come up with a better description.

What do you think of this?  I'm okay with removing the
whole second paragraph ("If the range is empty...") if you
think the first paragraph is already clear enough.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@item r @var{start},@var{end}
Step once, and then keep stepping as long as the thread stops at
addresses between @var{start} (inclusive) and @var{end} (exclusive).
The remote stub reports a stop reply when either the thread goes out
of the range or is stopped due to an unrelated reason, such as hitting
a breakpoint.  @xref{range stepping}.

If the range is empty (@var{start} == @var{end}), then the action
becomes equivalent to the @samp{s} action.  In other words,
single-step once, and report the stop (even if the stepped instruction
jumps to @var{start}).

(A stop reply may be sent at any point even if the PC is still within
the stepping range; for example, it is valid to implement this packet
in a degenerate way as a single instruction step operation.)

@end table
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Pedro Alves