Re: [discuss] Support for reverse-execution

[Michael Snyder <msnyder@redhat.com>]

Daniel Jacobowitz wrote:
> 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".

Yeah, I was thinking of "reverse-continue" as the long-form,
and anticipating one or more abbreviated aliases such as
rcontinue or rc.


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

Johan?  Is there a conversation that I missed?


> I wish one of you had noticed vCont though, at least as an
> example :-)

Thanks for bringing it to my (our) attention.

> [threads]

Yeah, as I currently think of it, reverse execution would
deterministically reiterate (or de-iterate) what happened
before -- therefore you cannot expect to change the course
of the execution while running in reverse.  Any interferance
with thread scheduling would change the outcome (income?)

If you first back up, and then shift into forward again,
that's another story...

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

My thinking was (admittedly old-school): just try it, and if the
target doesn't understand it, then report accordingly to the user.
But I'm totally open to other suggestions.


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

Sure.

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

Sure.  ;-)