RE: reverse for GDB/MI

["Jakob Engblom" <jakob@virtutech.com>]

> 	1. Use --reverse option

It looks like we are back to the --reverse discussion that we had before
Christmas. Most people seem to think that having specialized commands for
reverse execution makes more sense than having a special flag to certain
commands. 

For example, Michael Snyder wrote on 2008-12-18:
http://sourceware.org/ml/gdb-patches/2008-12/msg00351.html : 
----
> There are other reverse commands than the -exec-reverse-step that are more
> complicated. If you consider all reverse commands to be simple variants
> of the forward commands, then you are correct that there should just
> be a --reverse option. But I consider them to not be simple variants.

They're not simple variants.  Some of them have to deal with
issues like prologues vs. epilogues, stepping thru a return
back to the callee, etc.

It's mostly handled in infrun and infcmd, by checking the
"exec-direction" flag.

> You can also look at the documentation to see if the reverse commands are
> just variants of the forward variants. I do not think we can replace the
> documentation for reverse-step, reverse-step-instruction, reverse-continue,
> reverse-finish, reverse-next, and reverse-next-instruction and just say it
> is the reverse variant for the corresponding forward commands. Please look
> at the other reverse commands and see if you can say "reverse-finish" is
> just the reverse variant of finish.

Yeah -- it's not.  ;-)
It's an analogue, that's all.
----


And Tomas Holmberg: http://sourceware.org/ml/gdb-patches/2008-12/msg00319.html :
----
    I am not quite sure about adding new set of commands for that. Can we use
    --reverse option, thereby not introducing new commands?


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. I consider the
reverse commands as a new set commands and not a variant of the old.
----

Also, changing to variants would require rewriting code that we already have in
place and hvae tested (at least to some extent), and doing that always strikes
me as inviting problems and extra work.  

About the proliferation of commands, that seems to be in the nature of things
for reverse. The commands discussed here:

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

That is how we actually do things in Simics, and it turns out to be pretty
useful.  In our CLI, we have:

For basic control:

* continue [n]
* reverse  [n]
* run-seconds (value)
* reverse-to (value)
* skip-to (point in time)
* stepi [n]
* reverse-stepi [n]

And with debug info loaded:
* reverse-next-instruction  
* reverse-step-line       
* reverse-next-line         
* uncall-function


> 	3. Include documentation

Documentation for the reverse commands was submitted back in December too, as
far as I can tell (http://sourceware.org/ml/gdb-patches/2008-12/msg00312.html).
Did that miss being included into the source code?  

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

That makes sense to me too, the exec-direction concept is a bit strange.

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47   
Drottningholmsvägen 22      Mobile: +46 709 242 646  
11243 Stockholm             Web:    www.virtutech.com 
Sweden
________________________________________________________