Re: reverse for GDB/MI

[Vladimir Prus <vladimir@codesourcery.com>]

On Thursday 18 December 2008 12:15:29 Jakob Engblom wrote:
> > >> I am not quite sure about adding new set of commands for that. Can we use
> > >> --reverse option, thereby not introducing new commands?
> 
> What would be the gain from NOT adding the commands, as you see it? It certainly
> looks like the most straightforward and easy-to-understand solution. 
> 
> > >
> > > Adding a reverse option to the existing commands is possible. But I do
> > > not think it is a good idea. It is not always obvious what should
> > > happen when running a standard command in reverse.
> > 
> > Why? -exec-step always steps forward. -exec-step --reverse always steps
> > backward. Seems like a fairly simple model to me.
> 
> Overall, it is not that simple, unfortunately, and that is our experience from
> doing reverse execution on a large scale for the past four years. 
>
> First of all, the logic in the implementation side is very different for forward
> and backward step.  Second, going into that logic is simpler with a separate set
> of commands -- much easier both to send out and parse in the code, as the
> reverse bits are obviously separated.  Having a --reverse flag will force
> command handlers that only deal with the normal case to check for reverse and
> either return an error or take some other action. Why complicate it like that?

I assume that the 'set exec-direction' command happens to already work in FSF GDB?
Then, I'd claim that --reverse is actually trivial.

> If you cannot do reverse, having a set of reverse commands that is clearly
> defined by looking just at the command makes ignoring them easier.   

Ignoring where, by whom, and for what purpose?

> There is no 
> shortage of name space in MI, and thus I cannot see that there is any value to
> making things more complicated with an extra flag.

It seems to be that it's best to have some structure in MI commands and flags.
Say, we have continue and reverse-continue. What if you want some other form
of continue, say "continue for N seconds". Should we have then:

	continue
	reverse-continue
	timed-continue
	reverse-timed-continue

? That would be fairly cumbersome. Also, the --reverse option can be documented
with a single paragraph, whilst individual commands should all have individual
documentation.
 
> This is also inline with the gdb command line structure, and I think it eases
> understanding the system as a whole if all command interfaces use a similar
> semantic structure. 
> 
> Note that on a conceptual level there are new possibilities in reverse execution
> that do not exist in classic unidirectional debugging. For example, "go to time
> point P".  Since a classic unidirectional debugger can only stop or go forward,
> this concept did not exist in such a form.  This is not part of the current
> patch, but certainly can be seen to come up moving forward (or it might be
> already part of bookmarking in the reverse gdb). 

To summarize, I would like the patch to be adjusted in the following way:

	1. Use --reverse option
	2. Arrange for --exec-step, and similar, to ignore 'set exec-direction',
	since all new MI commands should strive to be stateless. This, of course,
	will mean that one cannot get existing frontend to do reverse step by
	typing a command into CLI console, but it is not obvious if existing
	frontend will work without modification anyway.
	3. Include documentation
	4. Include testcases

Thanks,
Volodya