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).

[Eli Zaretskii]

Date: Wed, 04 Jan 2006 13:00:31 -0800
So here is my proposed gdb user interface.
1) A set of new commands that mimic the existing ones,
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''.

New requests: "bs" (backward step), and "bc" (backward continue).

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

[Michael Snyder]

Post by Eli Zaretskii

Date: Wed, 04 Jan 2006 13:00:31 -0800
So here is my proposed gdb user interface.
1) A set of new commands that mimic the existing ones,
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?

[Eli Zaretskii]

Date: Thu, 05 Jan 2006 20:28:06 -0800

Post by Eli Zaretskii
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?

[Paul Koning]

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

[Bob Rossi]

Post by Paul Koning

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

[Eli Zaretskii]

Date: Fri, 13 Jan 2006 11:02:23 -0500

Post by Paul Koning
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.

[Dave Korn]

Post by Michael Snyder
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

[Eli Zaretskii]

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''.

[Dave Korn]

Post by Eli Zaretskii

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

[Eli Zaretskii]

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.

[Eli Zaretskii]

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.

[Dave Brolley]

Post by Dave Korn
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

[Daniel Jacobowitz]

Post by Michael Snyder
So here is my proposed gdb user interface.
1) A set of new commands that mimic the existing ones,
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.

Post by Michael Snyder
2) A mode setting that will cause all execution commands
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.

Post by Michael Snyder
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.

Post by Michael Snyder
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?

[Paul Gilliam]

Post by Daniel Jacobowitz

Post by Michael Snyder
So here is my proposed gdb user interface.
1) A set of new commands that mimic the existing ones,
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 #=-

[Daniel Jacobowitz]

Post by Paul Gilliam

Post by Daniel Jacobowitz

Post by Michael Snyder
So here is my proposed gdb user interface.
1) A set of new commands that mimic the existing ones,
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...

[Paul Gilliam]

Post by Daniel Jacobowitz

Post by Paul Gilliam

Post by Daniel Jacobowitz

Post by Michael Snyder
So here is my proposed gdb user interface.
1) A set of new commands that mimic the existing ones,
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-)

[Vladimir Prus]

Post by 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,
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.

Post by Michael Snyder
2) A mode setting that will cause all execution commands
set exec-direction [forward backward]
That gives users the choice of backing up once, or continuously.
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

[Julian Smith]

On Wed, 04 Jan 2006 13:00:31 -0800

Post by 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.

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/

Post by Michael Snyder
1) A set of new commands that mimic the existing ones,
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