This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reverse for GDB/MI


On Friday 06 February 2009 13:07:32 Jakob Engblom wrote:
> > 	1. Use --reverse option
>
> It looks like we are back to the --reverse discussion that we had before
> Christmas. 

Right, because no conclusion was ever reached on that discussion, to the
best of my knowledge.

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

I saw both these comments, and I still think that 'continue', for frontend,
is continue, no matter if that's going backward to some point in time, or just 
forward. Frontend does not care about prologues and epilogues, and stepping
back to caller, and anything like this.



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

Well, I don't remember that the design for MI reverse support was ever posted
to this list. If it were, you'd receive these comments before writing the code 
:-)

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

Well, this sounds fairly complicated to me.

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

I've missed that post on the first re-read of this thread.

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

Note that I have no position if exec-direction should remain in CLI, I just 
prefer that it does not affect MI.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]