Re: Return to Reverse Execution

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Jan 04, 2006 at 01:00:31PM -0800, Michael Snyder wrote:
> 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'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.

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

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.

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

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.

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

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?

-- 
Daniel Jacobowitz
CodeSourcery