Re: Return to Reverse Execution

[Vladimir Prus <ghost at cs dot msu dot su>]

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