Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz <drow at false dot org>]

On Fri, May 13, 2005 at 09:19:17AM +0300, Eli Zaretskii wrote:
> > I propose we add something like the following commands
> > (names open to discussion):
> > 
> > reverse-continue -- start executing backwards until something
> > interesting happens (most likely hitting a breakpoint).
> > 
> > reverse-stepi -- "un-execute" the previous instruction.
> > 
> > reverse-step -- "un-execute" the previous source line.
> > 
> > reverse-finish or "un-call" -- proceed backward until 
> > the current function is about to be called by its caller.
> > 
> > reverse-until... etc.
> 
> Not "reverse", "backwards" or "back".  "Reverse" will become ambiguous
> once we have two possible directions.

Actually I think "reverse" is a more logical term.  Drivers don't
seem to get confused when they put a car into reverse, which is a
natural parallel.  The program doesn't have a persistant direction.
If it's stopped, "continue" will always move forwards in time
and "reverse-continue" will always move backwards.

"back-step" is kind of appealing, but "back-continue" and "back-next"
just don't sound right.  I suppose we could use "continue-backwards"?

I would just have called the command rcontinue, but reverse-continue is
fine with me too; either way we'll hopefully offer abbreviations, like
"c" and "si".

> > Along with these commands, we would need at least two new
> > remote-protocol messages: "rc" for reverse-continue, and "rs" 
> > for reverse-stepi.  I think all of the above user commands could
> > be implemented on these primatives.  Obviously if the remote
> > target doesn't understand these primatives, the user command 
> > would error.

You used rc, Johan used bc.  It should be consistent with the command
names.  I wish one of you had noticed vCont though, at least as an
example :-)

`vCont'[;ACTION[`:'TID]]... -- extended resume
     Resume the inferior.  Different actions may be specified for each
     thread.  If an action is specified with no TID, then it is applied
     to any threads that don't have a specific action specified; if no
     default action is specified then other threads should remain
     stopped.  Specifying multiple default actions is an error;
     specifying no actions is also an error.  Thread IDs are specified
     in hexadecimal.  Currently supported actions are:

Hmm, thinking about this some more, maybe not such a bright idea. The
documentation would need some clarification, since even if we someday
have a simulator which both supports reverse execution and presents a
view of multiple threads (the implications are dizzying) I'm sure it
will be strictly limited in how you can back up the program.  Backing
up one thread while running another forwards, or even while leaving
another stopped, doesn't make sense - it creates a view of execution
which never occurred in the previous run.  However, there are still two
advantages to vCont: consistency, and a pre-existing query packet,
vCont?.

I'm not dead set on this idea; the benefits of consistency are pretty
small in this case and the thread-specific expressive power of vCont is
not obviously useful for reverse execution.  However I think a query
packet is still wise.  This allows a front end to modify its interface
based on whether the target supports reverse execution without having
to try it.

> > Finally, we'd need a new entry for the target vector --
> > something like "to_resume_backwards".  If the target vector
> > doesn't export this method, the user command would error.

Whichever name we settle on let's be consistent - if we use "reverse"
for the commands and documentation, we should use if for the target
hook too.

> Please don't forget the manual changes for these features.

Definitely!

-- 
Daniel Jacobowitz
CodeSourcery, LLC