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

Pedro Alves
2013-05-15T13:58:39Z

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