Re: reverse for GDB/MI

Vladimir Prus
2009-02-05T09:38:59Z

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