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

[Pedro Alves <palves@redhat.com>]

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.

Thanks!
-- 
Pedro Alves