This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/5] range stepping: gdb
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 15 May 2013 19:20:46 +0100
- Subject: Re: [PATCH 3/5] range stepping: gdb
- References: <20130514191026 dot 13213 dot 39574 dot stgit at brno dot lan> <20130514191047 dot 13213 dot 8476 dot stgit at brno dot lan> <83k3n173ao dot fsf at gnu dot org> <5193621C dot 50603 at redhat dot com> <83ppws5w00 dot fsf at gnu dot org> <519381E9 dot 3020007 at redhat dot com> <83bo8c5pb7 dot fsf at gnu dot org> <5193948A dot 9090609 at redhat dot 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