Return to Reverse Execution

Return to Reverse Execution

[Michael Snyder]

Over the past several months, there's been some great discussion
of this topic, and even some trial patches sent out for comment.

I'd like to start preparing a real submission for approval.
I'm testing the waters now, to see how close we may be to
converging on an acceptable interface spec.

So here is my proposed gdb user interface.
   1) A set of new commands that mimic the existing ones,
   to include:
	reverse-step (rs)
	reverse-next (rn)
	reverse-continue (rc)
	reverse-finish (rf)

   2) A mode setting that will cause all execution commands
   to be performed in reverse:
	set exec-direction [forward backward]

That gives users the choice of backing up once, or continuously.

Here's my proposed target vector interface:

   target_ops.to_set_exec_direction (int);

This keeps the target vector simple -- no need for discreet
vectors for reverse-proceed, reverse-wait etc.  If the target
doesn't export this method, it cannot go backwards.

And here's my proposed remote protocol interface:

New requests:  "bs" (backward step), and "bc" (backward continue).
Unlike the forward versions, they will not carry an argument for
a signal number to be passed to the target -- can't think how we
would implement signals in reverse...

Comment?


Footnote: I'm making this an interface spec, specifically to avoid
tying it to any model of implementation.  My idea is that GDB (core)
does not know *how* the target implements reverse execution -- and
does not care.  It could be by using checkpoints, it could be that
most of the work is done on the gdb side, or that most of the work
is done on the remote side.  The interface makes this invisible.  It
may work one way for remote, a different way for a direct simulator
interface, and a completely different way for native linux or hpux.
The details will be hidden either in the target module or on the
other side of the target interface (eg. remote protocol).

Postscript: It would probably also be a good idea to make up
an interface spec for checkpoints  --  this proposal doesn't
address that, as I argue that it's orthogonal to reverse execution
(except from the implementation side).

Re: Return to Reverse Execution

[Eli Zaretskii]

> Date: Wed, 04 Jan 2006 13:00:31 -0800
> From: Michael Snyder <msnyder@redhat.com>
> CC: Johan Rydberg <jrydberg@virtutech.com>,         "Frank Ch. Eigler" <fche@redhat.com>,         Dave Brolley <brolley@redhat.com>, Eric Bachalo <ebachalo@redhat.com>
> 
> So here is my proposed gdb user interface.
>    1) A set of new commands that mimic the existing ones,
>    to include:
> 	reverse-step (rs)
> 	reverse-next (rn)
> 	reverse-continue (rc)
> 	reverse-finish (rf)

May I raise again the issue of names?  That is, could we please
consider

	back-step
	previous
	back-continue
	back-finish

?  I think ``reverse'' is ambiguous: it doesn't actually say that we
are going backwards, just that we are reversing the direction, like
some kind of toggle.  Reverse would be okay if we had some global
direction flag which ``reverse'' command would reverse.  This is not
the case: these commands will _always_ go backwards, even if we
implement exec-direction and the user sets it to `backward'.

> 	set exec-direction [forward backward]

See, you used ``backward'' here, not ``reverse''.

> And here's my proposed remote protocol interface:
> 
> New requests:  "bs" (backward step), and "bc" (backward continue).

And here as well.  So it looks like your instincts prefer ``back'',
like mine ;-)

Re: Return to Reverse Execution

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Wed, 04 Jan 2006 13:00:31 -0800
>>From: Michael Snyder <msnyder@redhat.com>
>>CC: Johan Rydberg <jrydberg@virtutech.com>,         "Frank Ch. Eigler" <fche@redhat.com>,         Dave Brolley <brolley@redhat.com>, Eric Bachalo <ebachalo@redhat.com>
>>
>>So here is my proposed gdb user interface.
>>   1) A set of new commands that mimic the existing ones,
>>   to include:
>>	reverse-step (rs)
>>	reverse-next (rn)
>>	reverse-continue (rc)
>>	reverse-finish (rf)
> 
> 
> May I raise again the issue of names?  That is, could we please
> consider
> 
> 	back-step
> 	previous
> 	back-continue
> 	back-finish
> 
> ?  I think ``reverse'' is ambiguous: it doesn't actually say that we
> are going backwards, just that we are reversing the direction, like
> some kind of toggle.  Reverse would be okay if we had some global
> direction flag which ``reverse'' command would reverse.  This is not
> the case: these commands will _always_ go backwards, even if we
> implement exec-direction and the user sets it to `backward'.

Eli, I'm certainly willing to consider it, but as I review the
previous discussion, it seems like you were the only proponant
of these names.

I do like "previous", perhaps as a synonym or alias.
Come to that, alias-commands are easy, we could always
add these names as alternatives.

Anybody else feel that "back" or "backward" is a better prefix
than "reverse"?  Or perhaps that the syntax should be implemented
as a true command prefix?  With perhaps both alternatives allowed?

Re: Return to Reverse Execution

[Eli Zaretskii]

> Date: Thu, 05 Jan 2006 20:28:06 -0800
> From: Michael Snyder <msnyder@redhat.com>
> CC: gdb@sources.redhat.com, jrydberg@virtutech.com, fche@redhat.com,         brolley@redhat.com, ebachalo@redhat.com
> 
> > May I raise again the issue of names?  That is, could we please
> > consider
> > 
> > 	back-step
> > 	previous
> > 	back-continue
> > 	back-finish
> > 
> > ?  I think ``reverse'' is ambiguous: it doesn't actually say that we
> > are going backwards, just that we are reversing the direction, like
> > some kind of toggle.  Reverse would be okay if we had some global
> > direction flag which ``reverse'' command would reverse.  This is not
> > the case: these commands will _always_ go backwards, even if we
> > implement exec-direction and the user sets it to `backward'.
> 
> Eli, I'm certainly willing to consider it, but as I review the
> previous discussion, it seems like you were the only proponant
> of these names.

That might be so, but please note that you yourself used ``back'' and
``backward'' in almost every other place in your description except
the command names.  Doesn't this tell you something?

Re: Return to Reverse Execution

[Paul Koning]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

 >> Date: Thu, 05 Jan 2006 20:28:06 -0800 From: Michael Snyder
 >> Eli, I'm certainly willing to consider it, but as I review the
 >> previous discussion, it seems like you were the only proponant of
 >> these names.

 Eli> That might be so, but please note that you yourself used
 Eli> ``back'' and ``backward'' in almost every other place in your
 Eli> description except the command names.  Doesn't this tell you
 Eli> something?

I'll add my voice to Eli.  "Back" is a direction; "reverse" is (in one
of its meanings) a change of direction.

   paul

Re: Return to Reverse Execution

[Bob Rossi]

On Fri, Jan 06, 2006 at 10:19:36AM -0500, Paul Koning wrote:
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
>  >> Date: Thu, 05 Jan 2006 20:28:06 -0800 From: Michael Snyder
>  >> Eli, I'm certainly willing to consider it, but as I review the
>  >> previous discussion, it seems like you were the only proponant of
>  >> these names.
> 
>  Eli> That might be so, but please note that you yourself used
>  Eli> ``back'' and ``backward'' in almost every other place in your
>  Eli> description except the command names.  Doesn't this tell you
>  Eli> something?
> 
> I'll add my voice to Eli.  "Back" is a direction; "reverse" is (in one
> of its meanings) a change of direction.

Has anyone even considered "Previous", instead of "Back" or "Reverse"?
I mean, Previous/Next go together IMO, just as Backward/Forward go together.

It makes perfect sense to me to allow the user to go the the previous
executed line.

Bob Rossi

Re: Return to Reverse Execution

[Eli Zaretskii]

> Date: Fri, 13 Jan 2006 11:02:23 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: eliz@gnu.org, msnyder@redhat.com, gdb@sources.redhat.com,
> 	jrydberg@virtutech.com, fche@redhat.com, brolley@redhat.com,
> 	ebachalo@redhat.com
> 
> > I'll add my voice to Eli.  "Back" is a direction; "reverse" is (in one
> > of its meanings) a change of direction.
> 
> Has anyone even considered "Previous", instead of "Back" or "Reverse"?
> I mean, Previous/Next go together IMO, just as Backward/Forward go together.

For "next", "previous" is indeed a good counterpart.  But we were
mainly talking about the other commands: step, continue, finish,
until, etc.

RE: Return to Reverse Execution

[Dave Korn]

Michael Snyder wrote:

> 
> Anybody else feel that "back" or "backward" is a better prefix
> than "reverse"?  Or perhaps that the syntax should be implemented
> as a true command prefix?  With perhaps both alternatives allowed?


  I feel this is becoming a bikeshed colour issue :) and don't think it should
distract our attention!

  I think that if there is any potential confusion about what the terms might
mean in the context of having set the exec-direction reverse, then that simply
implies that the exec-direction command is superfluous and obfuscating, and
that all we need are one set of commands to go forwards, one set to go back,
and people can use the correct ones according to the direction they actually
want to go (which they should _know_ in any case!) rather than offering an
extra feature whose semantics would seem to be "Invert the meaning of what I
say as a convenience so that I can use the wrong command to do what I want".

[  IMOs, YMMVs, disclaimers and smilies go here....  ]

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Return to Reverse Execution

[Eli Zaretskii]

> From: "Dave Korn" <dave.korn@artimi.com>
> Cc: <gdb@sources.redhat.com>,
> 	<jrydberg@virtutech.com>,
> 	<fche@redhat.com>,
> 	<brolley@redhat.com>,
> 	<ebachalo@redhat.com>
> Date: Fri, 6 Jan 2006 10:30:40 -0000
> 
>   I think that if there is any potential confusion about what the terms might
> mean in the context of having set the exec-direction reverse, then that simply
> implies that the exec-direction command is superfluous and obfuscating, and
> that all we need are one set of commands to go forwards, one set to go back,
> and people can use the correct ones according to the direction they actually
> want to go

The main issue is not about the value of exec-direction, it is how to
call the commands that go backwards.  I suggested the prefix ``back''
or ``backwards'' instead of ``reverse''.

RE: Return to Reverse Execution

[Dave Korn]

Eli Zaretskii wrote:
>> From: "Dave Korn" <dave.korn@artimi.com>
>> Cc: <gdb@sources.redhat.com>,
>> 	<jrydberg@virtutech.com>,
>> 	<fche@redhat.com>,
>> 	<brolley@redhat.com>,
>> 	<ebachalo@redhat.com>
>> Date: Fri, 6 Jan 2006 10:30:40 -0000
>> 
>>   I think that if there is any potential confusion about what the terms
>> might mean in the context of having set the exec-direction reverse, then
>> that simply implies that the exec-direction command is superfluous and
>> obfuscating, and that all we need are one set of commands to go
>> forwards, one set to go back, and people can use the correct ones
>> according to the direction they actually want to go
> 
> The main issue is not about the value of exec-direction, it is how to
> call the commands that go backwards.  I suggested the prefix ``back''
> or ``backwards'' instead of ``reverse''.

  We're about to start going in circles here :-(

  I _know_ you suggested a different prefix.

  And the reason *why* you suggested it, according to how I read your post, is
because the meaning of "reverse" would be unclear as to whether it always
meant the backwards direction, or whether it would swap directions if the
exec-direction flag swapped value, and you are concerned that this might be a
source of confusion, and you feel that the particular naming scheme you
suggest would clear up the confusion.

  Which is why my response was to suggest that if there was no flag, there
would be no ambiguity, at which point the naming would be non-confusing no
matter which option was chosen, or even both.  And my argument for removing
the flag was that it not just eliminates this possible confusion thereby
allowing us more flexibility in the command-naming scheme, but also that the
flag adds no extra functionality in any case, and therefore we could do quite
well without it.

  Because I believe the *main* issue should not be finicky details of
command-naming conventions, but the serious structural issues of
implementation and internals design.

  I don't understand why you reply just to reiterate your point, without
responding or reacting to my analysis.  ISTM that eliminating the confusion
should have been a reasonable way to address your worries by *both* avoiding
any possible confusion *and* still allowing us to have both sets of
command-naming schemes as aliases.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Return to Reverse Execution

[Eli Zaretskii]

> From: "Dave Korn" <dave.korn@artimi.com>
> Cc: <msnyder@redhat.com>, 	<gdb@sources.redhat.com>, 	<jrydberg@virtutech.com>, 	<fche@redhat.com>, 	<brolley@redhat.com>, 	<ebachalo@redhat.com>
> Date: Fri, 6 Jan 2006 12:29:16 -0000
> 
>   I _know_ you suggested a different prefix.
> 
>   And the reason *why* you suggested it, according to how I read your post, is
> because the meaning of "reverse" would be unclear as to whether it always
> meant the backwards direction, or whether it would swap directions if the
> exec-direction flag swapped value, and you are concerned that this might be a
> source of confusion, and you feel that the particular naming scheme you
> suggest would clear up the confusion.

No, I suggested to use ``backwards'' because it is unambiguous even if
there's no flag.

Re: Return to Reverse Execution

[Eli Zaretskii]

> From: "Dave Korn" <dave.korn@artimi.com>
> Cc: <msnyder@redhat.com>,
> 	<gdb@sources.redhat.com>,
> 	<jrydberg@virtutech.com>,
> 	<fche@redhat.com>,
> 	<brolley@redhat.com>,
> 	<ebachalo@redhat.com>
> Date: Fri, 6 Jan 2006 12:29:16 -0000
> 
>   Because I believe the *main* issue should not be finicky details of
> command-naming conventions, but the serious structural issues of
> implementation and internals design.

I agree that design and coding are more important, but that doesn't
mean that a good intuitive UI is entirely unimportant.  I think
Michael did right when he decided to discuss the user interface in
advance of coding, and I wanted to contribute to that effort as much
as I could.  I feel quite strongly about the naming issues, even
though it might not show in my language.

Re: Return to Reverse Execution

[Dave Brolley]

Dave Korn wrote:

>>>  I think that if there is any potential confusion about what the terms
>>>might mean in the context of having set the exec-direction reverse, then
>>>that simply implies that the exec-direction command is superfluous and
>>>obfuscating, and that all we need are one set of commands to go
>>>forwards, one set to go back, and people can use the correct ones
>>>according to the direction they actually want to go
>>>      
>>>
I agree. I would be very easy to forget which 'direction' one is pointed 
in and issue the wrong command by mistake. Making the 'direction' 
explicit in each command eliminates this problem.

Whether the prefix is 'backward' or 'reverse' doesn't matter to me much. 
When I drive my car, putting it in reverse always makes it go backward 
when I hit the gas.  :-)

Dave

Re: Return to Reverse Execution

[Daniel Jacobowitz]

On Wed, Jan 04, 2006 at 01:00:31PM -0800, Michael Snyder wrote:
> So here is my proposed gdb user interface.
>   1) A set of new commands that mimic the existing ones,
>   to include:
> 	reverse-step (rs)
> 	reverse-next (rn)
> 	reverse-continue (rc)
> 	reverse-finish (rf)

I'm fine with these names.  I think that we are not going to reach a
consensus on whether "reverse" or "back" is better, but I don't think that
means we should offer both; I think we should just pick one, use it
consistently, and document it consistently.

>   2) A mode setting that will cause all execution commands
>   to be performed in reverse:
> 	set exec-direction [forward backward]
> 
> That gives users the choice of backing up once, or continuously.

I guess choice is good.  I'm not convinced that this is very useful,
but if it's easy... we can add it and see if people use it.

> Here's my proposed target vector interface:
> 
>   target_ops.to_set_exec_direction (int);
> 
> This keeps the target vector simple -- no need for discreet
> vectors for reverse-proceed, reverse-wait etc.  If the target
> doesn't export this method, it cannot go backwards.

There's no "etc" that I can see.  I would have suggested adding an
argument to proceed() and letting the GDB core handle any persistent
"direction" state, instead - otherwise most targets are going to have
to store the exec direction in a local variable, and the core will have
to keep track of what it last told the target, or call this
unconditionally before every proceed.

> And here's my proposed remote protocol interface:
> 
> New requests:  "bs" (backward step), and "bc" (backward continue).
> Unlike the forward versions, they will not carry an argument for
> a signal number to be passed to the target -- can't think how we
> would implement signals in reverse...

This isn't adequate unless you want to flat-out reject this for
threaded situations - I think we need to at least consider what it
would mean, first.  Should these live in vCont?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Return to Reverse Execution

[Paul Gilliam]

My $0.02:

On Friday 06 January 2006 11:57, Daniel Jacobowitz wrote:
> On Wed, Jan 04, 2006 at 01:00:31PM -0800, Michael Snyder wrote:
> > So here is my proposed gdb user interface.
> >   1) A set of new commands that mimic the existing ones,
> >   to include:
> > 	reverse-step (rs)
> > 	reverse-next (rn)
> > 	reverse-continue (rc)
> > 	reverse-finish (rf)
> 
> I'm fine with these names.  I think that we are not going to reach a
> consensus on whether "reverse" or "back" is better, but I don't think that
> means we should offer both; I think we should just pick one, use it
> consistently, and document it consistently.
> 
'back' has 57% fewer keystrokes than 'reverse'.

-=# Paul #=-

Re: Return to Reverse Execution

[Daniel Jacobowitz]

On Fri, Jan 06, 2006 at 02:31:00PM -0800, Paul Gilliam wrote:
> My $0.02:
> 
> On Friday 06 January 2006 11:57, Daniel Jacobowitz wrote:
> > On Wed, Jan 04, 2006 at 01:00:31PM -0800, Michael Snyder wrote:
> > > So here is my proposed gdb user interface.
> > >   1) A set of new commands that mimic the existing ones,
> > >   to include:
> > > 	reverse-step (rs)
> > > 	reverse-next (rn)
> > > 	reverse-continue (rc)
> > > 	reverse-finish (rf)
> > 
> > I'm fine with these names.  I think that we are not going to reach a
> > consensus on whether "reverse" or "back" is better, but I don't think that
> > means we should offer both; I think we should just pick one, use it
> > consistently, and document it consistently.
> > 
> 'back' has 57% fewer keystrokes than 'reverse'.

I intend to use the two-character variants all the time in practice...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Return to Reverse Execution

[Paul Gilliam]

On Friday 06 January 2006 13:52, Daniel Jacobowitz wrote:
> On Fri, Jan 06, 2006 at 02:31:00PM -0800, Paul Gilliam wrote:
> > My $0.02:
> > 
> > On Friday 06 January 2006 11:57, Daniel Jacobowitz wrote:
> > > On Wed, Jan 04, 2006 at 01:00:31PM -0800, Michael Snyder wrote:
> > > > So here is my proposed gdb user interface.
> > > >   1) A set of new commands that mimic the existing ones,
> > > >   to include:
> > > > 	reverse-step (rs)
> > > > 	reverse-next (rn)
> > > > 	reverse-continue (rc)
> > > > 	reverse-finish (rf)
> > > 
> > > I'm fine with these names.  I think that we are not going to reach a
> > > consensus on whether "reverse" or "back" is better, but I don't think that
> > > means we should offer both; I think we should just pick one, use it
> > > consistently, and document it consistently.
> > > 
> > 'back' has 57% fewer keystrokes than 'reverse'.
> 
> I intend to use the two-character variants all the time in practice...
> 

In that case, I guess 'rs' is bettern than 'bs'....   I get enough of that as it is  8-)

Re: Return to Reverse Execution

[Vladimir Prus]

Michael Snyder wrote:

> Over the past several months, there's been some great discussion
> of this topic, and even some trial patches sent out for comment.
> 
> I'd like to start preparing a real submission for approval.
> I'm testing the waters now, to see how close we may be to
> converging on an acceptable interface spec.
> 
> So here is my proposed gdb user interface.
>    1) A set of new commands that mimic the existing ones,
>    to include:
> reverse-step (rs)
> reverse-next (rn)
> reverse-continue (rc)
> reverse-finish (rf)

I think that you need to specify completely what each of the commands will
do. There sure will be some corner cases and it would be better to
understand them sooner or later, and for that we need explicit spec.

As an example, we have this code:

  foo();

  i = 10;

and we're standing at "i = 10" line. Then, "rn" will presumably execute the
entire "foo()" line. The problem is that when standing on "i = 10" line
user does not know if previous line is function call or not, and what
function is called, and so can't easily decide if he wants "rnext" or
"rstep" command. Even in GUI, visually scanning for the previous code line
is inconvenient. In TUI this will require extra "list" command.

Maybe, for reverse execution each "rn/rs" command should show the next line
that will be executed with "rn/rs" command, not the one that will be
executed by the following "n/s" command (that was just executed by
"rn/rs")?

Or show two code lines: one that will be executed by "step" and one that
will be executed by "reverse-step"?


BTW, what about "reverse-until"? Sure's that's just tbreak +
reverse-continue so emulating reverse-until in KDevelop will be easy, but
for command line reverse-until might be handy.

>    2) A mode setting that will cause all execution commands
>    to be performed in reverse:
> set exec-direction [forward backward]
> 
> That gives users the choice of backing up once, or continuously.
> 
> Here's my proposed target vector interface:
> 
>    target_ops.to_set_exec_direction (int);
> 
> This keeps the target vector simple -- no need for discreet
> vectors for reverse-proceed, reverse-wait etc.  If the target
> doesn't export this method, it cannot go backwards.

Looks reasonable.

- Volodya

Re: Return to Reverse Execution

[Julian Smith]

On Wed, 04 Jan 2006 13:00:31 -0800
Michael Snyder <msnyder@redhat.com> wrote:

> Over the past several months, there's been some great discussion
> of this topic, and even some trial patches sent out for comment.
> 
> I'd like to start preparing a real submission for approval.
> I'm testing the waters now, to see how close we may be to
> converging on an acceptable interface spec.
> 
> So here is my proposed gdb user interface.

We've been busy the past year or so making such a "reverse execution"
engine (we call it a bidirectional debugger).  It's debugger neutral,
but our first supported front end is gdb.  As such we've patched gdb-6.4
to provide support for our new commands.  Communication between gdb and
the bidirectional debugger engine is via a pair of FIFOs.

You can check it out at http://undo-software.com/


>    1) A set of new commands that mimic the existing ones,
>    to include:
> 	reverse-step (rs)
> 	reverse-next (rn)
> 	reverse-continue (rc)
> 	reverse-finish (rf)

We decided on using a `b' prefix to existing execution commands: bnext,
bnexti, bstep, bstepi, buntil and bfinish.  There are also new commands:
`bgoton' goes back to an arbitrary temporal position, `bgoto' goes back
to an arbitrary place (e.g. `bgoto foo.c:23') and `bget' displays the
current temporal position.

If gdb develops a set of standard commands, we'd definitely use them.
The above ones seem to work well, but might not cover all types of
reverse execution engines.

- Julian

-- 
http://undo-software.com/