This is the mail archive of the gdb@sources.redhat.com 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: [discuss] Support for reverse-execution


> Date: Fri, 20 May 2005 09:03:42 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Michael Snyder <msnyder@redhat.com>, gdb@sources.redhat.com
> 
> > > The program doesn't have a persistant direction.
> > 
> > I envision that adding this could be a natural extension.  Using
> > "backwards" rather than "reverse" will save us from the ambiguity if
> > we ever add such a feature.
> 
> I really don't think that we should have such a feature.  It seems like
> a crummy interface - a resume command which goes either forwards or
> backwards in time depending on some global state?

I actually don't hate the idea so much, but let's not argue about
hypothetical features.

> > > "back-continue" and "back-next" just don't sound right.
> > 
> > Neither does "reverse-next".  Perhaps we should use "prev" instead.
> 
> It seems to me that if we give them unique names, the logical parallel
> with existing commands may be lost.

I'd rather lose parallel based on literal similarity, than introduce
commands whose names contain an internal contradiction, like back-next
or reverse-next.  To me, "next" implicitly means "forward", similar to
your interpretation of "reverse" to mean "backward".

> But perhaps not.  Let's try for
> the full set:
> 	continue	reverse-continue
> 	step		reverse-step
> 	next		reverse-next
> 	stepi		reverse-stepi
> 	nexti		reverse-nexti
> 	until		reverse-until
> 	advance		reverse-advance
> 	finish		reverse-finish
> 
> I think that's the full set of reversible commands.  Which of them
> don't work?  I agree that reverse-next is a little weak, but everything
> else seems OK.

reverse-nexti is like reverse-next, reverse-advance has similar
problems, and reverse-finish is also awkward (since we don't
``finish'' anything, we get to the beginning, not the end).

> We could use r-prefixed commands.  I don't think that helps much, since
> we're already planning to offer abbreviations like "rs" and "rni", but
> they're my second-favorite choice:
>   rcontinue, rstep, rnext, rstepi, rnexti, runtil, radvance, rfinish

These are better, since the single `r' doesn't produce the kind of
contradictions that "reverse" does.

> This one's kind of nice, we could use suffixes instead.  But
> next-backwards is very awkward:
>   continue-backwards, step-backwards, next-backwards, stepi-backwards,
>   nexti-backwards, until-backwards, advance-backwards, finish-backwards

These are okay from the mnemonic point of view, but they have a big
disadvantage for a CLI junky such as myself: they make "next" etc.
ambiguous, and you need to type a long string to disambiguate the
commands that today have very short unambiguous abbreviations.

So it seems that, unless someone else comes up with a better idea,
rnext, rstep, etc. is the best compromise.


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