This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [discuss] Support for reverse-execution
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. ;-)