Re: [discuss] Support for reverse-execution

Re: [discuss] Support for reverse-execution

[Dan Shearer]

On Thu, 12 May 2005 16:08 Michael Snyder wrote at
http://sources.redhat.com/ml/gdb/2005-05/msg00145.html

> I'd like to start adding some commands to gdb to support targets
> that can perform reverse execution (eg. stepping backwards).
> This concept has been around for a number of years now, and I
> have access to a target (the Simics simulator from Virtutech)
> that does it quite handily.

I'm from Virtutech and I'd just like to put some context around this to
make the case that a reversible gdb is a very powerful tool, not just a
curiosity and certainly not specific to one company's simulator.
Reversibility takes some getting used to, so please bear with me for a
long-ish message.

Virtutech's Simics is a simulator, it does go backwards, and every
hacker who's seen it gets as excited as Michael. Simics has a debugger,
but it isn't as capable as gdb (by design) and Virtutech wants to
encourage the existance of a gdb that does reversibility.  Simics
already has a gdb stub. So that's why Virtutech is here on this list.

Personally I think reversibility is the biggest advance in debugging
since source code debugging. We've got massive and complicated codebases
we're working with today and we need better productivity.  Projects like
KDE, Samba and OpenOffice use valgrind+gdb. With reversibility
productivity will improve even more, I can't make valgrind reversible
but I can help with gdb. That's why I'm here in a personal capacity.

When Reversibility Becomes Useful
---------------------------------

From what I've learned with Simics, reversibility becomes a generally
useful technique when both the simulator and the problem have certain
characteristics.

The simulator needs to be able to save state universally on a networked
world of disparate computers and other electronic devices. If a whole
universe can't be run backwards including diagnostic tools running
inside the universe then reversibility loses a lot of its benefit. The
simulator must also be fast enough to debug problems in real time:
booting an OS must be reasonably quick, for example. And running
backwards must not be slow either, or debugging becomes frustrating

One benefit to the party trick of unbooting a binary-only OS is to see
whether it unboots nearly as quickly as it boots. If it does, chances as
this is reversible hardware that will improve your debugging a lot.

Reversibility helps debugging when the problem:

1. depends on rare circumstances related to a complicated network
environment, and/or

2. involves multiple large, unrelated codebases where the aggregate
behaviour is unpredictable, and/or

3. timing considerations are vital and the inputs are non-deterministic


Reversible Hardware Options
---------------------------

Right now the only fast and complete reversible hardware solution is
Simics, however there is a lot of work happening in the field.

More than a year ago CoVirt project (http://www.eecs.umich.edu/CoVirt/ )
implemented a logging/playback facility for User Mode Linux and modified
gdb to use this to provide reversible execution and debugging. The
project website has a paper titled "Debugging operating systems with
time-traveling virtual machines" that illustrates the point very well.

Around 1999 Cygnus' GPL SID simulator could execute backwards.
Development on reversibility didn't continue so I'm told because it was
seen as "party tricks". Besides SID had flexible hardware watchpoints
like "stop the CPU when an ethernet interrupt is fired" which reduced
the need to search for a particular point in execution for SID's
intended users.

There have been discussions around most of the free simulators talking
about how reversibility could be implemented. I'd guess QEMU is a likely
candidate from the interests of some of the contributors. Valgrind is
another obvious possibility.

The commercial Green Hills Time Machine system instruments real hardware
and then provides an interface for debugging it via Green Hills'
debugger that steps anywhere in the execution history of the hardware.
This might be like Michael Snyder's Tracepoints facility in gdb taken to
an extreme (I haven't used either.)

According to the prior art research done for the Simics Hindsight
whitepaper at http://virtutech.com, reversible hardware has been seen as
doable for over 30 years. Part of the problem has been in implementing
it in a very fast and general way, and the other part has been in
working out why it is so useful.

Current Availability
--------------------

Nobody outside Virtutech has access to Simics reversibility. Simics
Hindsight is due to go into (non-public) beta fairly soon. As part of
this, Virtutech has modified the Simics gdb stub so it can talk to a gdb
that supports reversibility, but this is also in-house for now. So while
Virtutech wants to have a discussion about making its closed-source
simulator available to the kinds of people who live on this list, nobody
has it yet.

Hopefully that explains what reversibility is, why it is important, and
why it is a very significant capability.

-- 
Dan Shearer
dan@shearer.org

Re: [discuss] Support for reverse-execution

[Dan Shearer]

On Tue, May 17, 2005 at 03:16:49AM +0930, Dan Shearer wrote:

> Personally I think reversibility is the biggest advance in debugging
> since source code debugging. We've got massive and complicated codebases
> we're working with today and we need better productivity.  Projects like
> KDE, Samba and OpenOffice use valgrind+gdb. With reversibility
> productivity will improve even more, I can't make valgrind reversible
> but I can help with gdb. That's why I'm here in a personal capacity.
> 
> When Reversibility Becomes Useful
> ---------------------------------
> 
> From what I've learned with Simics, reversibility becomes a generally
> useful technique when both the simulator and the problem have certain
> characteristics.

... going on to describe something that valgrind is unlikely ever to
become :-)

What I am trying to say, I suppose, is that I have learned from a very
general solution how debugging is helped by reversibility. I'm sure some
of this knowledge scales down to the vertical solutions, however as per
the example of Cygnus' SID simulator if you start looking at a
micro-level view it is possible to come to the conclusion "so why
bother?"

-- 
Dan Shearer
dan@shearer.org

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Tue, May 17, 2005 at 03:16:49AM +0930, Dan Shearer wrote:
> Around 1999 Cygnus' GPL SID simulator could execute backwards.
> Development on reversibility didn't continue so I'm told because it was
> seen as "party tricks". Besides SID had flexible hardware watchpoints
> like "stop the CPU when an ethernet interrupt is fired" which reduced
> the need to search for a particular point in execution for SID's
> intended users.

Does anyone else know the history of this - was any of this code in the
version of sid in the src repository?  Is any of it still there?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Frank Ch. Eigler]

Daniel Jacobowitz <drow@false.org> writes:

> On Tue, May 17, 2005 at 03:16:49AM +0930, Dan Shearer wrote:
> > Around 1999 Cygnus' GPL SID simulator could execute backwards.
> > Development on reversibility didn't continue so I'm told because it was
> > seen as "party tricks". [...]
> 
> Does anyone else know the history of this - was any of this code in the
> version of sid in the src repository?  Is any of it still there? [...]

sid provides the same sort of state save/restore facility that any
moderately sophisticated but not brilliant target would be able to,
like ordinary simulators and even UNIX kernels with process checkpoint
support.

sid does not perform single-stepping backward as a primitive, since
that is very complex in the general case (thus requiring a "brilliant"
particular proprietary simulator).

The point of the other simulation gentleman on this thread is that by
using state snapshots as the basic target-side primitive, one can
implement backward stepping on the gdb side in a way that will work
even with non-brilliant targets.  (By the way, this does not require
actual bulk transmission of the state snapshots to gdb, just some sort
of management protocol.)


- FChE

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Cc: Dan Shearer <dan@shearer.org>, gdb@sources.redhat.com
> From: fche@redhat.com (Frank Ch. Eigler)
> Date: 20 May 2005 20:05:13 -0400
> 
> The point of the other simulation gentleman on this thread is that by
> using state snapshots as the basic target-side primitive, one can
> implement backward stepping on the gdb side in a way that will work
> even with non-brilliant targets.  (By the way, this does not require
> actual bulk transmission of the state snapshots to gdb, just some sort
> of management protocol.)

This leads me to another idea.  Perhaps we should implement a
checkpointing infrastructure in GDB, and allow the user (perhaps not
by default, but as part of some mode) to go back to every place where
the program stopped, for whatever reason: breakpoint, watchpoint,
single-stepping, etc.  That is, each time the inferior stops, ask the
target for the information that fully describes its state, store that
state description, and allow the user to rewind the target to any of
the stored states.

I think this would be a great feature to have in all kinds of targets,
including native, since the user can then step forward from the
checkpoint to reach any point in between.

Think how many times you've did a "next" over a function call, just to
find out that the bug is inside the function which you just
overstepped, or did a "continue" just to find out at the next
breakpoint that the problem you are tracing happened in between this
and the previous stop location.  An ability to rewind back to the
previous stop is something to kill for in such situations.

(Btw, I vaguely remember that Turbo Debugger of yore had something
like that.  Hmmm... I should try to dig out my old copy of that and
see if I'm right.)

If we implement something like that, perhaps we could ditch all the
reverse-* commands whose names we are discussing at such length in
this thread, and instead implement only one command, called, say,
"rewind" or "backup" or some such.  That, and a set/show mode command
to enable checkpointing would be enough, I think, to have 99% of the
functionality originally suggested in this thread.

How would this suggestion of mine map to the remote targets and
simulators that support checkpointing on the target side?

Re: [discuss] Support for reverse-execution

[Russell Shaw]

Eli Zaretskii wrote:
>>Cc: Dan Shearer <dan@shearer.org>, gdb@sources.redhat.com
>>From: fche@redhat.com (Frank Ch. Eigler)
>>Date: 20 May 2005 20:05:13 -0400
>>
>>The point of the other simulation gentleman on this thread is that by
>>using state snapshots as the basic target-side primitive, one can
>>implement backward stepping on the gdb side in a way that will work
>>even with non-brilliant targets.  (By the way, this does not require
>>actual bulk transmission of the state snapshots to gdb, just some sort
>>of management protocol.)
> 
> 
> This leads me to another idea.  Perhaps we should implement a
> checkpointing infrastructure in GDB, and allow the user (perhaps not
> by default, but as part of some mode) to go back to every place where
> the program stopped, for whatever reason: breakpoint, watchpoint,
> single-stepping, etc.  That is, each time the inferior stops, ask the
> target for the information that fully describes its state, store that
> state description, and allow the user to rewind the target to any of
> the stored states.
> 
> I think this would be a great feature to have in all kinds of targets,
> including native, since the user can then step forward from the
> checkpoint to reach any point in between.
> 
> Think how many times you've did a "next" over a function call, just to
> find out that the bug is inside the function which you just
> overstepped, or did a "continue" just to find out at the next
> breakpoint that the problem you are tracing happened in between this
> and the previous stop location.  An ability to rewind back to the
> previous stop is something to kill for in such situations.
> 
> (Btw, I vaguely remember that Turbo Debugger of yore had something
> like that.  Hmmm... I should try to dig out my old copy of that and
> see if I'm right.)
> 
> If we implement something like that, perhaps we could ditch all the
> reverse-* commands whose names we are discussing at such length in
> this thread, and instead implement only one command, called, say,
> "rewind" or "backup" or some such.  That, and a set/show mode command
> to enable checkpointing would be enough, I think, to have 99% of the
> functionality originally suggested in this thread.
> 
> How would this suggestion of mine map to the remote targets and
> simulators that support checkpointing on the target side?

It'd be better to store the state of every step in to a circular buffer
of size 1000 (the user could change that size with a command). Then you
could just: "back 10"  to go to the point that would have been 10 steps
ago, or "back 3 myfunc" to go back to the third last call of myfunc().
That way, there's only one backwards command to remember, and maybe a
command to change the history buffer size.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Sat, 21 May 2005 20:30:16 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> Cc: gdb@sources.redhat.com
> 
> It'd be better to store the state of every step in to a circular buffer
> of size 1000 (the user could change that size with a command).

When you say ``it'd be better'', what is the alternative that you
think is worse than your suggestion?  What I wrote didn't say how many
previous states to remember, nor what data structure to use for that.

Also, I hope you don't mean ``every step'', but rather ``every stop''.
What I suggested didn't involve single-stepping the program, so GDB
can only collect the target state when the target stops, not after
each instruction.

> That way, there's only one backwards command to remember, and maybe a
> command to change the history buffer size.

That's essentially what I suggested: to have a single command to go
back to one of the places where we have enough information to restore
the target state.

Re: [discuss] Support for reverse-execution

[Russell Shaw]

Eli Zaretskii wrote:
>>Date: Sat, 21 May 2005 20:30:16 +1000
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>Cc: gdb@sources.redhat.com
>>
>>It'd be better to store the state of every step in to a circular buffer
>>of size 1000 (the user could change that size with a command).
> 
> When you say ``it'd be better'', what is the alternative that you
> think is worse than your suggestion?  What I wrote didn't say how many
> previous states to remember, nor what data structure to use for that.
> 
> Also, I hope you don't mean ``every step'', but rather ``every stop''.
> What I suggested didn't involve single-stepping the program, so GDB
> can only collect the target state when the target stops, not after
> each instruction.

Yes, that's what i meant (every step). It could be configureable so
that the policy can be set to every user-stop, every function call,
or disabled alltogether. The idea is that you could run from main()
until a segfault happens, then "back 10" and step thru the last few
actions.

>>That way, there's only one backwards command to remember, and maybe a
>>command to change the history buffer size.
> 
> That's essentially what I suggested: to have a single command to go
> back to one of the places where we have enough information to restore
> the target state.

I was hoping to have target state for all of the last 100 or 1000 steps.

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Sat, May 21, 2005 at 01:07:41PM +0300, Eli Zaretskii wrote:
> This leads me to another idea.  Perhaps we should implement a
> checkpointing infrastructure in GDB, and allow the user (perhaps not
> by default, but as part of some mode) to go back to every place where
> the program stopped, for whatever reason: breakpoint, watchpoint,
> single-stepping, etc.  That is, each time the inferior stops, ask the
> target for the information that fully describes its state, store that
> state description, and allow the user to rewind the target to any of
> the stored states.
> 
> I think this would be a great feature to have in all kinds of targets,
> including native, since the user can then step forward from the
> checkpoint to reach any point in between.

Two things.

One, it requires extensive additional support from the target.  State
is huge and complicated - multiple threads, file system operations,
network packets.  You need a target that supports checkpointing to do
this.  I'm told there are native platforms which could offer this - I
just don't know what any of them are.

Two, this is basically the same thing as the bookmarking feature
already proposed in this thread; just have GDB automatically take a
bookmark at every stop.

> If we implement something like that, perhaps we could ditch all the
> reverse-* commands whose names we are discussing at such length in
> this thread, and instead implement only one command, called, say,
> "rewind" or "backup" or some such.  That, and a set/show mode command
> to enable checkpointing would be enough, I think, to have 99% of the
> functionality originally suggested in this thread.

Not at all.  Here's a big use of reversible debugging: timing-sensitive
or otherwise very hard-to-reproduce problems.  You want to be able to
leave the program running, hooked up to a simulator and a debugger, and
then once the mysterious bug has occurred back up a little bit to see
why.

And the only way that checkpointing could be as user-friendly as
stepping would be if GDB emulated the latter on the former, I think
(already suggested).

> How would this suggestion of mine map to the remote targets and
> simulators that support checkpointing on the target side?

Just fine, all it needs is bookmarking.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Russell Shaw]

Eli Zaretskii wrote:
>>Date: Sat, 21 May 2005 20:30:16 +1000
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>Cc: gdb@sources.redhat.com
>>
>>It'd be better to store the state of every step in to a circular buffer
>>of size 1000 (the user could change that size with a command).
> 
> When you say ``it'd be better'', what is the alternative that you
> think is worse than your suggestion?  What I wrote didn't say how many
> previous states to remember, nor what data structure to use for that.
> 
> Also, I hope you don't mean ``every step'', but rather ``every stop''.
> What I suggested didn't involve single-stepping the program, so GDB
> can only collect the target state when the target stops, not after
> each instruction.

Yes, that's what i meant (every step). It could be configureable so
that the policy can be set to every user-stop, every function call,
or disabled alltogether. The idea is that you could run from main()
until a segfault happens, then "back 10" and step thru the last few
actions.

>>That way, there's only one backwards command to remember, and maybe a
>>command to change the history buffer size.
> 
> That's essentially what I suggested: to have a single command to go
> back to one of the places where we have enough information to restore
> the target state.

I was hoping to have target state for all of the last 100 or 1000 steps.

There could be two things the user chooses:

   When you go back to a previous point then start
   stepping, all you see is a replay of what happened, rather than any real
   interactive or live executions happening. When you step past the current
   context, then 'real' simulation is again happening as usual, or

   When you go back to a previous point then start
   stepping, then 'real' simulation is again happening as usual.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Sat, 21 May 2005 10:19:31 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com
> 
> One, it requires extensive additional support from the target.  State
> is huge and complicated - multiple threads, file system operations,
> network packets.  You need a target that supports checkpointing to do
> this.  I'm told there are native platforms which could offer this - I
> just don't know what any of them are.

Well, at least the Linux kernel developers could perhaps be persuaded
to add such a support.

> Two, this is basically the same thing as the bookmarking feature
> already proposed in this thread; just have GDB automatically take a
> bookmark at every stop.

Correct.  What I'm saying is that by adding this we would provide a
large part of user-level functionality that is served by the full set
of reverse-* commands, but with the advantages that:

  (a) the list of new commands is much smaller and thus simpler
  (b) we don't need to figure out the right semantics of tricky
      commands like "reverse-next" and "reverse-finish"
  (c) part of the implementation is on the GDB side (as opoosed to the
      target side), so it will be easier to enable it for more targets

> > If we implement something like that, perhaps we could ditch all the
> > reverse-* commands whose names we are discussing at such length in
> > this thread, and instead implement only one command, called, say,
> > "rewind" or "backup" or some such.  That, and a set/show mode command
> > to enable checkpointing would be enough, I think, to have 99% of the
> > functionality originally suggested in this thread.
> 
> Not at all.  Here's a big use of reversible debugging: timing-sensitive
> or otherwise very hard-to-reproduce problems.  You want to be able to
> leave the program running, hooked up to a simulator and a debugger, and
> then once the mysterious bug has occurred back up a little bit to see
> why.

Okay so perhaps it's less than 99%, but it's still a large portion.

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Sat, May 21, 2005 at 06:40:45PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 21 May 2005 10:19:31 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com
> > 
> > One, it requires extensive additional support from the target.  State
> > is huge and complicated - multiple threads, file system operations,
> > network packets.  You need a target that supports checkpointing to do
> > this.  I'm told there are native platforms which could offer this - I
> > just don't know what any of them are.
> 
> Well, at least the Linux kernel developers could perhaps be persuaded
> to add such a support.

Maybe.  It would be a major piece of surgery; I think that
checkpointing has been implemented before, but never merged.

> > Two, this is basically the same thing as the bookmarking feature
> > already proposed in this thread; just have GDB automatically take a
> > bookmark at every stop.
> 
> Correct.  What I'm saying is that by adding this we would provide a
> large part of user-level functionality that is served by the full set
> of reverse-* commands, but with the advantages that:
> 
>   (a) the list of new commands is much smaller and thus simpler
>   (b) we don't need to figure out the right semantics of tricky
>       commands like "reverse-next" and "reverse-finish"

But the new commands would be much less useful.  To me, at least.  Why
should we choose a lesser solution just to avoid figuring out the
complicated bits of a more thorough solution?

>   (c) part of the implementation is on the GDB side (as opoosed to the
>       target side), so it will be easier to enable it for more targets

(c) is Paul's and Frank's point.  I think that it should wait until
there's a target that doesn't provide it on the target side; I don't
see a problem in using it if it's available.

> > Not at all.  Here's a big use of reversible debugging: timing-sensitive
> > or otherwise very hard-to-reproduce problems.  You want to be able to
> > leave the program running, hooked up to a simulator and a debugger, and
> > then once the mysterious bug has occurred back up a little bit to see
> > why.
> 
> Okay so perhaps it's less than 99%, but it's still a large portion.

Well I can't (yet!) speak from experience, but I think that you're
leaving out the most useful bits.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Dan Shearer]

On Sat, May 21, 2005 at 01:43:32PM -0400, Daniel Jacobowitz wrote:
> On Sat, May 21, 2005 at 06:40:45PM +0300, Eli Zaretskii wrote:
> > > Date: Sat, 21 May 2005 10:19:31 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com
> > > 
> > > One, it requires extensive additional support from the target.  State
> > > is huge and complicated - multiple threads, file system operations,
> > > network packets.  You need a target that supports checkpointing to do
> > > this.  I'm told there are native platforms which could offer this - I
> > > just don't know what any of them are.
> > 
> > Well, at least the Linux kernel developers could perhaps be persuaded
> > to add such a support.
> 
> Maybe.  It would be a major piece of surgery; I think that
> checkpointing has been implemented before, but never merged.

You can get a feeling for how much work there is by looking at the
subset addressed in software suspend http://www.suspend2.net . And this
is just for part of one architecture on one operating system. Generic
checkpointing in Linux on all platforms would be wonderful to have but I
hardly think gdb reversibility will be a driving motivation. And even if
it existed:

	a) what about the heisenbugs? A checkpointable OS still isn't a
	disinterested party to a debugging session

	b) what about all the other OSs?

Maybe one day we'll get there, but in the meantime the only realistic
solution I know of is to do simulation in a userspace process, because
then checkpointing becomes a solvable problem. Not always an easy
problem because of issues with things like SMP and cranky peripherals
but it is at least possible to have the checkpointing mechanism out of
the scope of the OS being checkpointed/debugged.

-- 
Dan Shearer
dan@shearer.org

Re: [discuss] Support for reverse-execution

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Fri, 20 May 2005 14:16:29 -0700
>>From: Michael Snyder <msnyder@redhat.com>
>>
>> > Sounds like a very useful feature.  However, I think we need to
>> > support giving meaningful names to bookmarks, since a (more or less
>> > arbitrary) number used by the target is going to lack any mnemonic
>> > value.
>>
>>How about counting numbers, like we do with breakpoints?
> 
> 
> That might be okay as well, but I consider the method of numbering
> breakpoints as not an ideal one, either.  It's impossible to manage
> more than 3 breakpoints without "info breakpoints".  More mnemonic
> names could have allowed us to know what breakpoint we need to use
> without consulting the table displayed by "info breakpoints".

OK, then maybe we should make this a general feature -- add a
name field for breakpoints, tracepoints, checkpoint/bookmarks,
and in general such things as we have such lists for.  Looking
ahead, people may one day want to give names to threads, or
even sets-of-threads.

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> Russell Shaw <rjshaw at netspace dot net dot au> writes:
> Yes, that's what i meant (every step). It could be configureable so
> that the policy can be set to every user-stop, every function call,
> or disabled alltogether. The idea is that you could run from main()
> until a segfault happens, then "back 10" and step thru the last few
> actions.

There's nothing inherently wrong with the strategy, as long as one
understands that the utility it provides can be deceptive; for example
given the following simple program fragment:

void foo(void)
{
   x = the_real_problem();
   for (int i = x, i != 0, ++i)
   {
     something();
   }
}

foo();  // step from here.
... ;   // to here.

It's clear that tracing and recording the last N states can easily
be consumed in uninteresting code.

A similar strategy may constrain the N full state traces/snapshots
to only entries into basic blocks, which both allows N to be smaller,
while simultaneously enabling a broader swipe of interesting locations
to recorded for subsequent inspection. This ideally either requires that
the compiled program be analyzed to apriority identify these entry points,
although a close approximation may be determined at runtime by only
recording state traces at points of control flow change; i.e. capture and
record state only upon a given condition, (typically when the PC != PC + 1,
for example), or may be generalized to any arbitrary set of "watch-point"
conditions; as an incremental nicety, not unlike the HW trace history buffer
support that some processors provide. (and could be enabled by GDB directly,
with or without target support)

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> From: Daniel Jacobowitz <drow@false.org>
>> On Sat, May 21, 2005 at 10:13:04AM -0400, Paul Schlie wrote:
>>> When someone implements reversible debugging in a free simulator and
>>> wants to integrate that with GDB, they'll have the choice of doing the
>>> remaining steps in their simulator or in GDB.
>> 
>> - Although our views may differ, I accept and support the simple reality
>>   that those to invest the time and resources in a development, have the
>>   greatest say in the decisions. (In this case if the desire is to define
>>   an interface for a single lone proprietary tool, likely in satisfaction or
>>   natural result of a commercial commercial contract to do so, then let it
>>   be; but attempting to justify it as a good thing is a bit of a stretch).
> 
> Paul, I have said repeatedly in this discussion that I think this is a
> natural, valid, good interface to the functionality.  That's my
> considered opinion; I am not trying to justify anything by it.
> 
> Please take a deep breath and stop tossing accusation around if you
> want to be taken seriously.

- Agreed, sorry.

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> From: Daniel Jacobowitz <drow@false.org>
>> On Fri, May 20, 2005 at 09:52:45PM -0400, Daniel Jacobowitz wrote:
>> Frank has contributed that sid would more readily support the sort of
>> snapshot-based reconstruction that you're talking about (thanks Frank).
>> I think that allowing the target to provide infrun with a view in which
>> "single step backwards" is possible and then implementing that under
>> the covers in the target stack would still be the way to go - but I
>> don't think that's a legitimate objection to supporting a smart
>> simulator which does it internally.
> 
> BTW, a thought to consider - again, one which will only be interesting
> when there's a system to which it applies.
> 
> What most of these single-stepping commands want to do, in the absence
> of watchpoints, is see the PC sequence over a timeline, choose a
> stopping state, and go to that state.  For some simulator it may be
> substantially more efficient to just ask the target for a history of PC
> values for some number of cycles, all at once, and then tell it which
> one of those we're interested in.  That would work for reverse-next,
> for example.

- Tracing a subset of the states is one thing, tracing and recording all
  states can be quite another; where like most things, the significance
  of "some" vs. "all" is relative to the detail inherent in the model of
  the system being simulated. In the simplest ISA simulation case without
  attempting to model a complex HW world around the processor in detail,
  it's not necessarily unreasonable to record all of the most recent N
  cycle states, presuming N is large enough to be useful; although tracing
  anything likely reduces simulation performance by at least a factor of 10
  vs. tracing nothing between termination points, it's not likely a big deal
  when a typical simulation interval may only otherwise require a fraction
  of a second, but can easily become a big deal when the complexity of a
  simulation may otherwise be measured in minutes (as the very nature of
  interactive debugging implies some minimal latency so the pilot doesn't
  feel compelled to take naps while attempting to interactively analyze
  their system's behavior between supposedly interactive requests; as
  otherwise things become counterproductive, as the pilot can easily
  loose their train of thought).

> I don't know the level of computation involved in these snapshots in
> Simics; perhaps an intelligent simulator, when told to go backwards,
> would reconstruct a series of "frames" all at once and cache them, so
> this is a non-issue.  For some other simulator not yet available,
> perhaps it's not.

- Not to be too redundant, but just to try to emphasis the one point
  which I do feel is important; which is that it's likely important for
  GBD to initially define a set of commands which are most likely easily
  supported, as it's likely better to have broad multiple target support
  for a simpler set of capabilities, than very limited target support for
  a sophisticated set of capabilities in the absents of the former;
  "undo/reverse" essentially represents this minimal baseline command
  functionality, all others are substantially more complex to support in
  the general case.

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Sat, May 21, 2005 at 10:13:04AM -0400, Paul Schlie wrote:
> > When someone implements reversible debugging in a free simulator and
> > wants to integrate that with GDB, they'll have the choice of doing the
> > remaining steps in their simulator or in GDB.
> 
> - Although our views may differ, I accept and support the simple reality
>   that those to invest the time and resources in a development, have the
>   greatest say in the decisions. (In this case if the desire is to define
>   an interface for a single lone proprietary tool, likely in satisfaction or
>   natural result of a commercial commercial contract to do so, then let it
>   be; but attempting to justify it as a good thing is a bit of a stretch).

Paul, I have said repeatedly in this discussion that I think this is a
natural, valid, good interface to the functionality.  That's my
considered opinion; I am not trying to justify anything by it.

Please take a deep breath and stop tossing accusation around if you
want to be taken seriously.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> From: Daniel Jacobowitz <drow@false.org>
> On Fri, May 20, 2005 at 09:41:58PM -0400, Paul Schlie wrote:
>> - Supporting HW co-simulation is certainly interesting, but fundamentally
>>   no different; it only extends the definition of "state" typically by
>>   literally exposing some of the logical CPU/I/O/Peripheral/outside-world
>>   state in various levels of details depending on the goals of the model,
>>   and/or simulation itself. (but would guess likely beyond the near term
>>   goals of attempting to enable GDB support for basic reversible execution?)
> 
> Why should it be?  This is another reason that I consider the simulator
> a perfectly reasonable place to have the logic.

- The predominant downside of such a presumption, is that then NxM targets
  would need to add support to broadly enable the capability, rather than
  broadly enabling within GDB, while allowing a target to improve it.
  
> Frank has contributed that sid would more readily support the sort of
> snapshot-based reconstruction that you're talking about (thanks Frank).
> I think that allowing the target to provide infrun with a view in which
> "single step backwards" is possible and then implementing that under
> the covers in the target stack would still be the way to go.

- Possibly the only reasonable way to do, as the ability to "single step
  backwards" to a state with the simulation environment may have never
  previously terminated at is substantially more difficult to support
  efficiently than simply reverting to a previously reached stable state.

> - but I don't think that's a legitimate objection to supporting a smart
> simulator which does it internally.

- I only object (or observe alternatives) to defining a set of commands
  which are presently apparently unique to a particular commercial tool's
  abilities, and which if presumed to form the basis of the requirements
  for reversible simulation could become an impediment for GDB to support
  simpler more easily implemented facilities. Conversely, if it were
  initially presumed that the initial basis for reversible simulation were
  based on the support of a recursive "undo/reverse" command, then it would
  be much easier for a broader number of targets (and even potentially GDB
  itself) to support.

> When someone implements reversible debugging in a free simulator and
> wants to integrate that with GDB, they'll have the choice of doing the
> remaining steps in their simulator or in GDB.

- Although our views may differ, I accept and support the simple reality
  that those to invest the time and resources in a development, have the
  greatest say in the decisions. (In this case if the desire is to define
  an interface for a single lone proprietary tool, likely in satisfaction or
  natural result of a commercial commercial contract to do so, then let it
  be; but attempting to justify it as a good thing is a bit of a stretch).

>>   [And suspect you'll find that most HW savvy simulation environments have
>>    very limited if any support for "reversible" simulation, beyond
>>    checkpoint-restart. As on a cycle by cycle basis, tracking and recording
>>    incremental state changes would typically cripple the simulation, and
>>    potentially even exhaust disk storage for complex models, but limited
>>    forms do exist, and are useful.]
> 
> You might want to read the papers on the specific simulator we're
> discussing using as a starting point; you can find the white paper on
> Virtutech's web site.  Under the covers, of course, it's probably
> checkpoint based.  But it's efficient, automatic checkpointing such
> that it can provide a reversible view over useful periods of time.
> Complete with "HW savvy" details.

- Thank you.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Fri, 20 May 2005 14:51:17 -0700
> From: Michael Snyder <msnyder@redhat.com>
> 
> Make me a third person who thought of it independantly.
> 
> Look at it this way -- once we've implemented the reverse-x
> command set, adding this would be trivial; just a single
> set/show mode variable.  Then we could evaluate both, or even
> leave it to the user to choose.

The problem is, once we implement such a mode, the word "reverse"
becomes ambiguous: it no longer unambiguously says that we go
backwards.

That prospect was the original reason I mentioned the possibility of
introducing such a mode in the future.  And that was the reason I
still think it's better, at least in principle, to say "backwards" or
"back", because that's unambiguous.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Fri, 20 May 2005 14:16:29 -0700
> From: Michael Snyder <msnyder@redhat.com>
> 
>  > Sounds like a very useful feature.  However, I think we need to
>  > support giving meaningful names to bookmarks, since a (more or less
>  > arbitrary) number used by the target is going to lack any mnemonic
>  > value.
> 
> How about counting numbers, like we do with breakpoints?

That might be okay as well, but I consider the method of numbering
breakpoints as not an ideal one, either.  It's impossible to manage
more than 3 breakpoints without "info breakpoints".  More mnemonic
names could have allowed us to know what breakpoint we need to use
without consulting the table displayed by "info breakpoints".

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 09:52:45PM -0400, Daniel Jacobowitz wrote:
> Frank has contributed that sid would more readily support the sort of
> snapshot-based reconstruction that you're talking about (thanks Frank).
> I think that allowing the target to provide infrun with a view in which
> "single step backwards" is possible and then implementing that under
> the covers in the target stack would still be the way to go - but I
> don't think that's a legitimate objection to supporting a smart
> simulator which does it internally.

BTW, a thought to consider - again, one which will only be interesting
when there's a system to which it applies.

What most of these single-stepping commands want to do, in the absence
of watchpoints, is see the PC sequence over a timeline, choose a
stopping state, and go to that state.  For some simulator it may be
substantially more efficient to just ask the target for a history of PC
values for some number of cycles, all at once, and then tell it which
one of those we're interested in.  That would work for reverse-next,
for example.

I don't know the level of computation involved in these snapshots in
Simics; perhaps an intelligent simulator, when told to go backwards,
would reconstruct a series of "frames" all at once and cache them, so
this is a non-issue.  For some other simulator not yet available,
perhaps it's not.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 09:41:58PM -0400, Paul Schlie wrote:
> - Supporting HW co-simulation is certainly interesting, but fundamentally
>   no different; it only extends the definition of "state" typically by
>   literally exposing some of the logical CPU/I/O/Peripheral/outside-world
>   state in various levels of details depending on the goals of the model,
>   and/or simulation itself. (but would guess likely beyond the near term
>   goals of attempting to enable GDB support for basic reversible execution?)

Why should it be?  This is another reason that I consider the simulator
a perfectly reasonable place to have the logic.

Frank has contributed that sid would more readily support the sort of
snapshot-based reconstruction that you're talking about (thanks Frank).
I think that allowing the target to provide infrun with a view in which
"single step backwards" is possible and then implementing that under
the covers in the target stack would still be the way to go - but I
don't think that's a legitimate objection to supporting a smart
simulator which does it internally.

When someone implements reversible debugging in a free simulator and
wants to integrate that with GDB, they'll have the choice of doing the
remaining steps in their simulator or in GDB.

>   [And suspect you'll find that most HW savvy simulation environments have
>    very limited if any support for "reversible" simulation, beyond
>    checkpoint-restart. As on a cycle by cycle basis, tracking and recording
>    incremental state changes would typically cripple the simulation, and
>    potentially even exhaust disk storage for complex models, but limited
>    forms do exist, and are useful.]

You might want to read the papers on the specific simulator we're
discussing using as a starting point; you can find the white paper on
Virtutech's web site.  Under the covers, of course, it's probably
checkpoint based.  But it's efficient, automatic checkpointing such
that it can provide a reversible view over useful periods of time. 
Complete with "HW savvy" details.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> From: Daniel Jacobowitz <drow@false.org>
>> On Fri, May 20, 2005 at 06:42:45PM -0400, Paul Schlie wrote:
>> - Which is fully your right to claim/believe; however noting the absence
>>   of non-proprietary simulators with these capabilities (it's a little
>>   unclear how one can presume that interfaces are likely most ideally
>>   necessary or appropriate; and simply note that register and memory state
>>   by definition is program state, which GDB already has direct access to).
> 
> That is incorrect.  There can be considerably more state.  For
> instance, I understand from Dan's explanation that Simics will reply
> external interrupt sources - at the same clock cycles where they would
> otherwise have occurred.

- Supporting HW co-simulation is certainly interesting, but fundamentally
  no different; it only extends the definition of "state" typically by
  literally exposing some of the logical CPU/I/O/Peripheral/outside-world
  state in various levels of details depending on the goals of the model,
  and/or simulation itself. (but would guess likely beyond the near term
  goals of attempting to enable GDB support for basic reversible execution?)

  [And suspect you'll find that most HW savvy simulation environments have
   very limited if any support for "reversible" simulation, beyond
   checkpoint-restart. As on a cycle by cycle basis, tracking and recording
   incremental state changes would typically cripple the simulation, and
   potentially even exhaust disk storage for complex models, but limited
   forms do exist, and are useful.]

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 06:42:45PM -0400, Paul Schlie wrote:
> - Which is fully your right to claim/believe; however noting the absence
>   of non-proprietary simulators with these capabilities (it's a little
>   unclear how one can presume that interfaces are likely most ideally
>   necessary or appropriate; and simply note that register and memory state
>   by definition is program state, which GDB already has direct access to).

That is incorrect.  There can be considerably more state.  For
instance, I understand from Dan's explanation that Simics will reply
external interrupt sources - at the same clock cycles where they would
otherwise have occurred.

>   As an aside and personal opinion, I happen believe it's not likely good
>   form to define "opaque" interfaces to non-FSF tools without at least
>   simultaneously implementing a non-opaque/proprietary solution (which is
>   I guess the same philosophical problem that I have with the sourcing of
>   any information, including potentially proprietary extended register/ISA
>   definitions through an "opaque" interface/wall).

It's no more opaque than the continue command is opaque.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> From: Michael Snyder <msnyder@redhat.com>
>>>> or presume the intelligence need be "remote" to GDB;
>>> 
>>> We're not doing that either -- the user interface makes no
>>> assumption about the target interface.
>> 
>> - Then there seems no need to define a reverse-xxxx set of commands
>> at the GDB/target-stub boundary (unless I misunderstand the purposed
>> of the earlier threads of dialog)?
> 
> <tag-dont-take-this-as-criticism>
> The user interface makes no *assumption* about the target
> interface, but that doesn't mean that the target doesn't
> *also* need an interface.  Both have been discussed in this
> thread, but they're not tied together.

- I'd just caution against defining user commands which are in general
  much more difficult and expensive to support; i.e. defining any
  command which may specify a state which has not been previously likely
  recorded, as then it implies that the state needs to be unwound to the
  closest known point preceding it and then forward executed to the new
  desired state (which the simulation may have never "stopped" at before)

  More specifically for example, one may step past a function call, where
  the state preceding and after the call is now known, but the state
  preceding the previous instruction reverse-step-i may not be supported
  by the simulator naturally, and may require that the simulation be undone
  (which is always easiest) to the point preceding the call and then forward
  executed until the desired preceding instruction state is reached, etc.

  (Therefore an "undo/reverse" command is most likely the best basis for
  basic reverse simulation support, as it restricts reverse execution to
  only those points which the simulator had previously terminated it's
  simulation at previously; and other commands may be best only defined
  after such features are more broadly supported by at least a few
  simulators, and/or by GDB directly. Just as a thought.)

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> From: Daniel Jacobowitz <drow@false.org>
>> On Fri, May 20, 2005 at 06:01:44PM -0400, Paul Schlie wrote:
>>> From: Dan Shearer <dan@shearer.org>
>>> In the longer term yes, GDB should be able to debug with a sense of
>>> direction and time. But I think it will take quite a bit of experimentation
>>> before we have a clear model of how to do this, and the only way I can think
>>> of for both having a reversible GDB and not touching GDB too much is by
>>> considering remote targets first.
>> 
>> - Then you'll end up with nothing more than an interface to a propriety
>>   simulator, which doesn't seem like a good goal or approach for GDB.
> 
> This argument is so bogus that I need to call you on it.  You end up
> with a reasonable interface to _any_ simulator, whether proprietary or
> not.  The details of an efficient implementation will be obviously
> dependent on the simulator's state and implementation.

- Which is fully your right to claim/believe; however noting the absence
  of non-proprietary simulators with these capabilities (it's a little
  unclear how one can presume that interfaces are likely most ideally
  necessary or appropriate; and simply note that register and memory state
  by definition is program state, which GDB already has direct access to).

> I am inclined to agree with the posted proposals that the
> implementation of reverse-stepi should be opaque to GDB, at least for
> now.  The performance of shuffling state diffs over the remote protocol
> - or even just references to them - would be horrid.  It also means
> that GDB will be limited to a particular class of implementations of
> reversible simulation instead of the concept of reversible simulation.

- There's no magic, defining a interface for a non-existent simulator
  doesn't yield a functional solution, and given the absents of knowledge
  of what that the "typical" simulator's interface presumptions are seems
  a little premature to define in lieu of a solution.

  As an aside and personal opinion, I happen believe it's not likely good
  form to define "opaque" interfaces to non-FSF tools without at least
  simultaneously implementing a non-opaque/proprietary solution (which is
  I guess the same philosophical problem that I have with the sourcing of
  any information, including potentially proprietary extended register/ISA
  definitions through an "opaque" interface/wall).
  
> You're describing something which may be interesting, someday.  Do feel
> welcome to implement it; we'll be glad to help.  I don't think that
> it's inherently more appropriate than the proposed interface, though.

- It was just offered as a potential alternative based on a different
  philosophical view; which I may consider doing something with as time
  and inclination may allow, and do appreciate the offer for assistance
  if/when that time comes.

  

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 05:37:17PM +0300, Eli Zaretskii wrote:
> That's an interesting subtle point.  At first I wanted to say "the
> former", but then I remembered the issue with moving a word forward
> and backward in editors.  With some editors, such as Emacs,
> forward-word ends up one character _before_ the beginning of the next
> word, while backward-word ends up on the first character of the
> previous word.  Other editors end up on the first character of a word
> with either forward or backward movement.

More precisely, emacs' forward-word appears to put your cursor at the
end of the current word, unless it was already there, in which case you
go to the end of the next word.  Similarly previous-word takes you to
the beginning of the current word, unless you're already there.

[The difference from what Eli wrote is purely pedantic - try it with
multiple spaces between words.  Not an issue for us :-)]

> So it could make sense for GDB to stop at the _last_ instruction of
> the previous source line when we move backwards by lines.  The
> question is, will this be useful for the user.  I'm not sure; perhaps
> they will want to skip all the code of the line and stop before its
> first instrcution, like "next" does.

Even the Emacs idea would work: back to the beginning of this source
line.  I think that beginning of the previous source line will be the
most generally useful; the beginning of source lines is a more useful
place for the debugger to go than the end, because the interface is
much more apparent that the line "really" hasn't been execute yet.

In any case, this is a subtle point - let's flag this subthread and
make sure we write it down!  And test it, if possible! :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Michael Snyder]

 >>> or presume the intelligence need be "remote" to GDB;
 >>
 >> We're not doing that either -- the user interface makes no
 >> assumption about the target interface.
 >
 > - Then there seems no need to define a reverse-xxxx set of commands
 > at the GDB/target-stub boundary (unless I misunderstand the purposed
 > of the earlier threads of dialog)?

<tag-dont-take-this-as-criticism>
The user interface makes no *assumption* about the target
interface, but that doesn't mean that the target doesn't
*also* need an interface.  Both have been discussed in this
thread, but they're not tied together.

We have, for instance, discussed six or seven user commands
(not counting bookmarks), but AFAIK only two target interface
commands should be needed to support them -- "rc/bc" and "rs/bs".

There's a third interface we've discussed too -- the interface
between core-gdb and the target or back-end component (eg. but
not limited to remote.c).  We might, for instance, add a single
new method to the target vector, eg. "to_resume_backwards"
(or we might just add a direction parameter to the existing one).
That method could then be added to, for instance, target sim.

All that said, I'm not taking issue with your idea.
I do think there might be a generic way for gdb to
do something like dropping a checkpoint.  I just don't
think its mutually exclusive with this discussion.

If you want to propose it in a separate thread, I'd be
thrilled to talk about it.

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 06:01:44PM -0400, Paul Schlie wrote:
> > From: Dan Shearer <dan@shearer.org>
> > In the longer term yes, GDB should be able to debug with a sense of
> > direction and time. But I think it will take quite a bit of experimentation
> > before we have a clear model of how to do this, and the only way I can think
> > of for both having a reversible GDB and not touching GDB too much is by
> > considering remote targets first.
> 
> - Then you'll end up with nothing more than an interface to a propriety
>   simulator, which doesn't seem like a good goal or approach for GDB.

This argument is so bogus that I need to call you on it.  You end up
with a reasonable interface to _any_ simulator, whether proprietary or
not.  The details of an efficient implementation will be obviously
dependent on the simulator's state and implementation.

I am inclined to agree with the posted proposals that the
implementation of reverse-stepi should be opaque to GDB, at least for
now.  The performance of shuffling state diffs over the remote protocol
- or even just references to them - would be horrid.  It also means
that GDB will be limited to a particular class of implementations of
reversible simulation instead of the concept of reversible simulation.

You're describing something which may be interesting, someday.  Do feel
welcome to implement it; we'll be glad to help.  I don't think that
it's inherently more appropriate than the proposed interface, though.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> From: Dan Shearer <dan@shearer.org>
>> On Fri, May 20, 2005 at 11:49:08AM -0400, Paul Schlie wrote:
>> Rather than... presume the intelligence need be "remote" to GDB;
>     :
>> I wonder if it may be more sensible to consider initially defining the basic
>> generic facilities by which GDB may directly support undoable/reversible
>> execution, and checkpoint features.
> 
> An alternative point of view: right now nobody has deep experience with
> reversible debugging and so it seems a little early to make
> across-the-board structure changes based on limited understanding.

- Actually I have intimate familiarity with simulation architecture and
  check-pointed reversible simulation.

> In the longer term yes, GDB should be able to debug with a sense of
> direction and time. But I think it will take quite a bit of experimentation
> before we have a clear model of how to do this, and the only way I can think
> of for both having a reversible GDB and not touching GDB too much is by
> considering remote targets first.

- Then you'll end up with nothing more than an interface to a propriety
  simulator, which doesn't seem like a good goal or approach for GDB.

> In general I really like the idea of GDB better catering to non-remote
> simulators. You'll notice that almost none of the whole-system
> simulators in the free software world have integrated debugging and I'd
> love to make that easier. It's just that the reversibility property is
> new and I think it will take some getting used to.

- I've basically already described how to do this in a generalized way.

>> More specifically, as ISA semantics do not generally have deterministic
>> reciprocal semantics,
> 
> What do you mean by "ISA" in this context?

- The sum total of all defined instructions semantic effects on machine
  and program data memory state.

>> Therefore it seems likely sufficient to initially begin by defining
>> support for the following core facilities:
>> 
>> Basic GDB support for check pointing and reverse execution:
>> 
>> - enable-checkpoints: initializes machine state and program memory to
>>   all 0's upon prior to program startup/initialization. (see below)
> 
> Isn't this getting out of scope for GDB's current design? If you're
> going to provide this meta-system command to the simulator why not
> provide others, like "load-image-file <filename>" to initialise the
> simulator or "enable-skip-idle" to make the simulator skip idle loops
> and other simulator-specific commands.
> 
> Again, I like the idea of making GDB closer to simulated environments,
> but I think it probably needs to be a specific choice to do this rather
> than just as a byproduct of supporting reversibility.

- What's interesting is that "reverse" execution is actually very simple,
  once it's understood that you can't generally "reverse execute", but only
  back-up to a previous state; then it becomes clear that all that's
  necessary is to define a method by which state-differences are extracted,
  and then unwound, on an command by command basis, not dissimilarly to how
  "undo" is typically handled by text editors, etc. (one may try to do
  fancier things, but will be found not to likely be worth it.)

>> - (step, next, etc.): as normal, but requests the state-diff from the
>>   target stub between successive command executions if reverse-execution
>>   flag is enabled. (This may also be supported without target stub support
>>   for state-diff, as GDB has direct access to both the target's machine
>>   state, and memory state; although target stubs may likely be capable
>>   of more efficient diff's if they are capable of tracking memory updates
>>   more efficiently than simply looking after the fact.)
> 
> Can you explain what kind of a facility you imagine GDB might have to
> support doing diffs inherently?

- How about simply defining that the diff-address/diff-extent/diff-values be
  recorded in an indexed file for any differences found between the previous
  memory state, and the now current memory state; where the previous memory
  state is stored in a sequential file, and the present is obtained from the
  target, then computing the diff, and saving the current memory state in
  the file replacing the previously defined previous memory state.

>> Basic Target stub facilities to improve reverse execution efficiently:
>> 
>> - state-diff: the target returns the diff between the target's present
>>   state and it's previous state, which may be used if available in lieu
>>   of GDB directly calculating machine and memory state diffs, but would
>>   likely only be substantially more efficient if the target stub were
>>   capable of more efficiently tracking and accumulating diffs by directly
>>   monitoring memory state changes, rather than determining them after
>>   the fact, as may be done likely efficiently by a target simulator and
>>   then simply communicated by publishing the cumulative diffs as requested
>>   by GDB; which seems nice and simple, and minimally invasive.)
> 
> Unless I've misunderstood you are proposing that GDB have the ability to
> accept and manipulate entire memory state and diffs of memory state.
> This is quite a large chunk of new functionality.

- It may be a lot of memory, but it's just a diff between two sequential
  data streams (as roughly described above if done by bruit force; which is
  likely fine for many embedded targets; and the only option if it's not a
  "simulated" target).

Re: [discuss] Support for reverse-execution

[Michael Snyder]

 >>     (gdb) reverse-step
 >>     # reverse-stepi once (or until we leave the *current* line)
 >
 > BTW, this bit is a little more complicated, because we might go
 > to another frame.  So we might have to do some reverse-finish's
 > stacked in there.

Absolutely -- I just wanted to focus on the one point.

 > I think infrun will need some serious cleaning
 > up to pull this off.

infrun *always* needs serious cleaning up.   ;-)

Seriously, though, we'll have to add some new state,
but I think it's doable without major rewriting.

Re: [discuss] Support for reverse-execution

[Michael Snyder]

 >>> Would not it be better to have a single "reverse" command which
 >>> puts the debugger in "reverse" mode -- making step/stepi/next/nexti
 >>> go backward.
 >>
 >> Daniel, I rest my case ;-)
 >
 > I don't rest mine :-)  I admit I was a little surprised to see
 > someone else suggest it, but I still think it's an awful idea as
 > a user interface.

Make me a third person who thought of it independantly.

Look at it this way -- once we've implemented the reverse-x
command set, adding this would be trivial; just a single
set/show mode variable.  Then we could evaluate both, or even
leave it to the user to choose.

Re: [discuss] Support for reverse-execution

[Michael Snyder]

 > Would not it be better to have a single "reverse" command which
 > puts the debugger in "reverse" mode -- making step/stepi/next/nexti
 > go backward.
 >
 > This might be handier for UI -- after all "step" can be abbreviated
 > as 's', but reverse-step can't be abbreviated. This might be better
 > in GUI too -- instead of doubling the number of "step" commands
 > you'd have a single "gear" switch, that can be in either "forward"
 > or "reverse" position.
 >
 > - Volodya

I'm certainly not opposed to that, although I lean a bit more
toward the separate "analogue" commands.

Fortunately, command interface is easy to implement.
Maybe we will float several independant patches that
each implement a different CLI to the same functionality,
so we can try them all out and get a feel for them.

Re: [discuss] Support for reverse-execution

[Paul Schlie]

> From: Michael Snyder <msnyder@redhat.com>
>> Paul Schlie wrote:
>> Alternatively to attempting to specify an interface to a lone commercial
>> reversible simulator,
> 
> I don't think that's what we're doing -- these commands are meant
> to be generically useful, as soon as anyone else can support
> backwards execution.

- Sorry for the misinterpretation; but as noted, it seems generally more
  useful to simply add the capability to GDB, thereby little if any
  functionality need be dependant on the target simulator, and further by
  doing so may actually support both check-pointing and undo/reverse
  execution, on all existing targets, regardless of whether or not they are
  simulated, or physical targets.
 
>> or presume the intelligence need be "remote" to GDB;
> 
> We're not doing that either -- the user interface makes no
> assumption about the target interface.

- Then there seems no need to define a reverse-xxxx set of commands at the
  GDB/target-stub boundary (unless I misunderstand the purposed of the
  earlier threads of dialog)?

>> I wonder if it may be more sensible to consider initially defining the basic
>> generic facilities by which GDB may directly support undoable/reversible
>> execution, and checkpoint features.
> 
> Well, that's an idea that some of us (me, at least...) have  thought about
> too -- but it's, if not orthogonal, at least separable from this discussion.
> If gdb asks the target to step backwards or continue backwards, we really
> don't care how the target accomplishes this

- Sounds like you are presuming the "intelligence" to be remote and distinct
  from GDB, which I believe is fundamentally a less than an ideal premise.

> (eg. whether by restoring a saved state, or actually reversing the execution
> of individual instructions).

- It should be clearly understood that it's factually impossible to define
  reciprocal semantics for all instructions; therefore the fundamental basis
  of any undo/reverse execution facility has to be based on the ability to
  capture state to revert the "effects" of the execution, not "execute"
  logically reciprocal instructions. (If this is not understood, then its
  likely premature to attempt to define any interface to support the
  capability.)

> I've thought all along that the "bookmark" idea is separable from the
> "run backwards" idea.

- There're essentially identical, with the exception that one captures
  and provides a vehicle to backup to a previously named/designated
  (bookmarked) state, the other enables the same but to typically to a
  previously relative state. (single-step reverse execution in it's most
  general implementation is nothing more than reversing to a previously
  sequentially captured instruction by instruction check point diff)

By recognizing this, there's no need to rely on any information beyond that
which GDB already has access to to implement (although may be improved by
by simulators which can capture memory state change diffs more efficiently
than by brute force)

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 02:16:29PM -0700, Michael Snyder wrote:
> >> It would be an interesting discussion to see how bookmarks could be
> >> incorporated into the gdb framework.
> >
> > Sounds like a very useful feature.  However, I think we need to
> > support giving meaningful names to bookmarks, since a (more or less
> > arbitrary) number used by the target is going to lack any mnemonic
> > value.
> 
> How about counting numbers, like we do with breakpoints?
> 
>     (gdb) get-bookmark
>     Bookmark #1, line 12, foo.c == <quasi-random-identifier>
>     (gdb) continue
>     Breakpoint 5, line 144, grbx.c
>     (gdb) info bookmarks
>     Bookmark   ID    Location
>     1          <###> foo.c line 12
>     (gdb) goto-bookmark 1
>     Line 12, foo.c (bookmark <quasi-random-identifier>)

I think Eli's right... why not let the user give them real names?  We
can give them sequential numbers, too, if we want.  I'd probably end up
naming all my bookmarks "q", cause that's the sort of person I am,
but...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

[Michael, if you get a chance, please update your address book; I'm not
@mvista.com any more.]

On Fri, May 20, 2005 at 02:11:25PM -0700, Michael Snyder wrote:
> I agree with this interpretation.  If I am a user (and I am),
> and I were to say:
>     (gdb) step
>     (gdb) reverse-step (or whatever)
> I would expect to be back where I started, ie. at the
> *beginning* of the original line.
> 
> Dan J. has said that we might need to reverse-stepi until
> we've gone back one too many, and then do a forward step.
> I agree.  In fact, I think it will be necessary to do
> the following:

After reading this a couple of times, I'm pretty sure you're right. 
Consider:

line:	foo
line2:	inc $r1
	cmp $r1, 64
	bne line
line3:  bar		# $pc points here

Reverse stepi from the inc may go to the bne, but we want to stop when
reverse stepi from the inc would go to the foo instead.

We don't have a lot of opportunity to make sure we're really where we
want to be when we're going forwards.  When we're going backwards,
though, we do.  Let's use it!

>     (gdb) reverse-step
>     # reverse-stepi once (or until we leave the *current* line)

BTW, this bit is a little more complicated, because we might go to
another frame.  So we might have to do some reverse-finish's stacked in
there.  I think infrun will need some serious cleaning up to pull this
off.

>     # now establish the step-range start and end (prev line)
>     # reverse-stepi until we leave the prev line
>     # stepi once to get back to the desired line.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Michael Snyder]

 > In general I really like the idea of GDB better catering to
 > non-remote simulators. You'll notice that almost none of the
 > whole-system simulators in the free software world have
 > integrated debugging and I'd >love to make that easier.

Traditionally, that's how we used to do it, and we still can
(see src/sim).  I think we've tended in the direction of letting
the sim be a separate program because sims like SID are so big.
Linking them in to gdb would make both huge.

The approach of using the remote protocol is very flexible.
The debugger and the sim can be running on the same host,
or on opposite sides of the planet.  If they're on the same
host, running packets thru a socket really doesn't slow us
down all that much.  But there is a function-call interface
for linking gdb to a sim if its wanted.

Re: [discuss] Support for reverse-execution

[Michael Snyder]

 >> It would be an interesting discussion to see how bookmarks could be
 >> incorporated into the gdb framework.
 >
 > Sounds like a very useful feature.  However, I think we need to
 > support giving meaningful names to bookmarks, since a (more or less
 > arbitrary) number used by the target is going to lack any mnemonic
 > value.

How about counting numbers, like we do with breakpoints?

     (gdb) get-bookmark
     Bookmark #1, line 12, foo.c == <quasi-random-identifier>
     (gdb) continue
     Breakpoint 5, line 144, grbx.c
     (gdb) info bookmarks
     Bookmark   ID    Location
     1          <###> foo.c line 12
     (gdb) goto-bookmark 1
     Line 12, foo.c (bookmark <quasi-random-identifier>)

Re: [discuss] Support for reverse-execution

[Michael Snyder]

In regards to the question "where does a reverse-step put you?"
(ie. at the beginning of a line, or somewhere in the line):

 > Sorry, I'm confused.  Isn't it right that if I'm stepping
 > backwards through code such as this:
 >
 >    i += 1;
 >    foo (i);
 >  =>i = 0;
 >
 > where "=>" shows the current source line, then typing `rnext'
 > once will get me to this:
 >
 >    i += 1;
 >  =>foo (i);
 >    i = 0;
 >
 > which means I'm now before the CALL insn that calls `foo'?

I agree with this interpretation.  If I am a user (and I am),
and I were to say:
     (gdb) step
     (gdb) reverse-step (or whatever)
I would expect to be back where I started, ie. at the
*beginning* of the original line.

Dan J. has said that we might need to reverse-stepi until
we've gone back one too many, and then do a forward step.
I agree.  In fact, I think it will be necessary to do
the following:

     (gdb) reverse-step
     # reverse-stepi once (or until we leave the *current* line)
     # now establish the step-range start and end (prev line)
     # reverse-stepi until we leave the prev line
     # stepi once to get back to the desired line.

Re: [discuss] Support for reverse-execution

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Fri, 20 May 2005 12:02:26 -0700
>>From: Michael Snyder <msnyder@redhat.com>
>>CC: Eli Zaretskii <eliz@is.elta.co.il>
>>
>> >> +extern enum step_direction_kind step_direction;
>> >
>> > Yuk! a global variable!
>>
>>That's entirely typical, Eli, for a "set/show" mode variable.
> 
> 
> Except that this wasn't a set/show mode variable at all.  It was a
> bona fide argument to be passed to target_resume.

Oh, sorry.  Guess I was thinking ahead to the idea of
having a user-setable direction mode.

Re: [discuss] Support for reverse-execution

[Michael Snyder]

Paul Schlie wrote:
> Alternatively to attempting to specify an interface to a lone commercial
> reversible simulator,

I don't think that's what we're doing -- these commands are meant
to be generically useful, as soon as anyone else can support
backwards execution.

> or presume the intelligence need be "remote" to GDB;

We're not doing that either -- the user interface makes no
assumption about the target interface.

> I wonder if it may be more sensible to consider initially defining the basic
> generic facilities by which GDB may directly support undoable/reversible
> execution, and checkpoint features.

Well, that's an idea that some of us (me, at least...) have
thought about too -- but it's, if not orthogonal, at least
separable from this discussion.  If gdb asks the target to
step backwards or continue backwards, we really don't care
how the target accomplishes this (eg. whether by restoring
a saved state, or actually reversing the execution of individual
instructions).

I've thought all along that the "bookmark" idea is separable
from the "run backwards" idea.

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 01:48:10PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> 
> >It seems to me that if we give them unique names, the logical parallel
> >with existing commands may be lost.  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. 
> 
> reverse-return?  <shudder>

Thank the lord, we don't have to worry about that one.  It isn't
possible.  Not even kinda.  I mean... uh... where would you go?
Bookmarks fill a sort of similar role.

> What if, in addition to what you describe above, we defined
> a *prefix* command "backwards" -- which would simply modify
> the other commands, eg. "backwards continue" (no hyphen)
> would call continue with whatever parameters would make it
> proceed backwards (or would call reverse-continue, or whatever).
> 
> Maybe this is too many ways to do the same thing, but
> it would cost us essentially nothing...
> 
> Furthermore, we could implement as many of these interfaces
> as we wish, hidden in "maintainer mode" or something, and
> try them out -- see how we like them.

True.  I think that's a little excessive, but at this point there do
seem to be three useful sets of names: reverse-continue, rcontinue, and
rc.  I'd support using all three.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Michael Snyder]

Daniel Jacobowitz wrote:

> It seems to me that if we give them unique names, the logical parallel
> with existing commands may be lost.  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. 

reverse-return?  <shudder>

 > Which of them
> don't work?  I agree that reverse-next is a little weak, but everything
> else seems OK.  And we aren't limited to one name for things!  We could
> add "prev" as an alias to "next" if you like that.

I like these, as being the most informative, with shorter and perhaps
more mnemonic versions  (such as prev) as aliases.  Eli, you should
like these because they're somewhat self-documenting (not that we'd
want to skimp on the real docs)

> 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
> 
> We could use "backwards" for everything.  Those mostly sound right,
> except that backwards has some unfortunate connotations. 

What if, in addition to what you describe above, we defined
a *prefix* command "backwards" -- which would simply modify
the other commands, eg. "backwards continue" (no hyphen)
would call continue with whatever parameters would make it
proceed backwards (or would call reverse-continue, or whatever).

Maybe this is too many ways to do the same thing, but
it would cost us essentially nothing...

Furthermore, we could implement as many of these interfaces
as we wish, hidden in "maintainer mode" or something, and
try them out -- see how we like them.

 > I think
> that advance and finish come out as particularly odd:
>   backwards-continue, backwards-step, backwards-next, backwards-stepi,
>   backwards-nexti, backwards-until, backwards-advance, backwards-finish
> 
> 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
> 

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Fri, 20 May 2005 12:02:26 -0700
> From: Michael Snyder <msnyder@redhat.com>
> CC: Eli Zaretskii <eliz@is.elta.co.il>
> 
>  >> +extern enum step_direction_kind step_direction;
>  >
>  > Yuk! a global variable!
> 
> That's entirely typical, Eli, for a "set/show" mode variable.

Except that this wasn't a set/show mode variable at all.  It was a
bona fide argument to be passed to target_resume.

Re: [discuss] Support for reverse-execution

[Michael Snyder]

Daniel Jacobowitz wrote:

> I would just have called the command rcontinue, but reverse-continue is
> fine with me too; either way we'll hopefully offer abbreviations, like
> "c" and "si".

I can't remember if I said this already, but...

If you look at gcore.c, you'll see that the actual name of the command
is "generate-core-file".  Then it's aliased to the shorter "gcore".

That's what I had in mind here.  A long-but-descriptive form
(which perhaps no one will ever type), and one or more short
forms such as rcontinue and rc.

Re: [discuss] Support for reverse-execution

[Stan Shebs]

Vladimir Prus wrote:

>
>Would not it be better to have a single "reverse" command which puts the
>debugger in "reverse" mode -- making step/stepi/next/nexti go backward.
>
>
In general, modes are bad for UI; people, even smart software
engineers, are not good at remembering modes. Think of how many
fenderbenders are caused by drivers stepping on the gas and
going in the opposite direction of what they expected. Coming
back to GDB, think of when you are using "up" and "down", then
ask to print a variable and get a complaint there is no such
variable, because you forgot which frame is current.

So I think the basic commands should be "reverse-foo" or
"back-foo" or whatever. That said, it would be pretty easy to layer
a mode on top of those for experimentation purposes, let everybody
try it out for awhile, and see what they tend to favor. For
instance, I can see a usage where a user will want to go back and
forth over a single complicated line multiple times, looking at
different variables in each step/rstep pair.

Stan

Re: [discuss] Support for reverse-execution

[Michael Snyder]

 >> +extern enum step_direction_kind step_direction;
 >
 > Yuk! a global variable!

That's entirely typical, Eli, for a "set/show" mode variable.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Fri, 20 May 2005 14:14:15 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> On Fri, May 20, 2005 at 06:54:13PM +0300, Eli Zaretskii wrote:
> > > From: Vladimir Prus <ghost@cs.msu.su>
> > > Date: Fri, 20 May 2005 18:45:22 +0400
> > > 
> > > Would not it be better to have a single "reverse" command which puts the
> > > debugger in "reverse" mode -- making step/stepi/next/nexti go backward.
> > 
> > Daniel, I rest my case ;-)
> 
> I don't rest mine :-)  I admit I was a little surprised to see someone
> else suggest it, but I still think it's an awful idea as a user
> interface.

Just to clarify: ``my case'' was not to suggest to add this feature,
but that someone some day might suggest to add it, and that such a
suggestion might be accepted.

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 06:54:13PM +0300, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 20 May 2005 18:45:22 +0400
> > 
> > Would not it be better to have a single "reverse" command which puts the
> > debugger in "reverse" mode -- making step/stepi/next/nexti go backward.
> 
> Daniel, I rest my case ;-)

I don't rest mine :-)  I admit I was a little surprised to see someone
else suggest it, but I still think it's an awful idea as a user
interface.  While the "gear" switch is clever, a GUI might still want
to use different icons for "next" and "rnext".  And whichever way the
GDB CLI and MI interfaces expose this functionality, a GUI can just as
easily reuse the same buttons for both.

The only advantage I see would be letting a GUI support it without
having to know that the feature exists, by passing a command to GDB and
then using the existing buttons.  Seems of dubious use.

I don't know yet whether direction during a debugging session is going
to be persistant or frequently changing.  Only one way to find out...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Dan Shearer]

On Fri, May 20, 2005 at 11:49:08AM -0400, Paul Schlie wrote:
> Rather than... presume the intelligence need be "remote" to GDB;
    :
> I wonder if it may be more sensible to consider initially defining the basic
> generic facilities by which GDB may directly support undoable/reversible
> execution, and checkpoint features.

An alternative point of view: right now nobody has deep experience with
reversible debugging and so it seems a little early to make
across-the-board structure changes based on limited understanding.

In the longer term yes, GDB should be able to debug with a sense of
direction and time. But I think it will take quite a bit of
experimentation before we have a clear model of how to do this, and the
only way I can think of for both having a reversible GDB and not
touching GDB too much is by considering remote targets first.

In general I really like the idea of GDB better catering to non-remote
simulators. You'll notice that almost none of the whole-system
simulators in the free software world have integrated debugging and I'd
love to make that easier. It's just that the reversibility property is
new and I think it will take some getting used to.

> More specifically, as ISA semantics do not generally have deterministic
> reciprocal semantics, 

What do you mean by "ISA" in this context?

> Therefore it seems likely sufficient to initially begin by defining
> support for the following core facilities:
> 
> Basic GDB support for check pointing and reverse execution:
> 
> - enable-checkpoints: initializes machine state and program memory to
>   all 0's upon prior to program startup/initialization. (see below)

Isn't this getting out of scope for GDB's current design? If you're
going to provide this meta-system command to the simulator why not
provide others, like "load-image-file <filename>" to initialise the
simulator or "enable-skip-idle" to make the simulator skip idle loops
and other simulator-specific commands.

Again, I like the idea of making GDB closer to simulated environments,
but I think it probably needs to be a specific choice to do this rather
than just as a byproduct of supporting reversibility.

> - (step, next, etc.): as normal, but requests the state-diff from the
>   target stub between successive command executions if reverse-execution
>   flag is enabled. (This may also be supported without target stub support
>   for state-diff, as GDB has direct access to both the target's machine
>   state, and memory state; although target stubs may likely be capable
>   of more efficient diff's if they are capable of tracking memory updates
>   more efficiently than simply looking after the fact.)

Can you explain what kind of a facility you imagine GDB might have to
support doing diffs inherently?

> Basic Target stub facilities to improve reverse execution efficiently:
> 
> - state-diff: the target returns the diff between the target's present
>   state and it's previous state, which may be used if available in lieu
>   of GDB directly calculating machine and memory state diffs, but would
>   likely only be substantially more efficient if the target stub were
>   capable of more efficiently tracking and accumulating diffs by directly
>   monitoring memory state changes, rather than determining them after
>   the fact, as may be done likely efficiently by a target simulator and
>   then simply communicated by publishing the cumulative diffs as requested
>   by GDB; which seems nice and simple, and minimally invasive.)

Unless I've misunderstood you are proposing that GDB have the ability to
accept and manipulate entire memory state and diffs of memory state.
This is quite a large chunk of new functionality.

-- 
Dan Shearer
dan@shearer.org

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 20 May 2005 18:45:22 +0400
> 
> Would not it be better to have a single "reverse" command which puts the
> debugger in "reverse" mode -- making step/stepi/next/nexti go backward.

Daniel, I rest my case ;-)

Re: [discuss] Support for reverse-execution

[Paul Schlie]

Alternatively to attempting to specify an interface to a lone commercial
reversible simulator, or presume the intelligence need be "remote" to GDB;
I wonder if it may be more sensible to consider initially defining the basic
generic facilities by which GDB may directly support undoable/reversible
execution, and checkpoint features.

More specifically, as ISA semantics do not generally have deterministic
reciprocal semantics, it's only possible to support reverse execution
by literally being able to either maintain a list of all state changes
associated with each instruction/command's execution and unwind them,
and then optionally proceed forward again.

Therefore it seems likely sufficient to initially begin by defining
support for the following core facilities:

Basic GDB support for check pointing and reverse execution:

- enable-checkpoints: initializes machine state and program memory to
  all 0's upon prior to program startup/initialization. (see below)

- save-checkpoint [Optional-Name] => checkpoint [N [Optional-Name]],
  saves a diff between the programs present state and it's previous
  state, and marks the current undo-state diff (see below) as being
  equivalent to this checkpoint.

- restore-checkpoint [N | Opional-Name]; sets machine and memory state
  to the cumulative difference between all 0's and the designated
  checkpoint diff. [this is insensitive to the target's stub supporting
  state-diff, as GBD is responsible for storing and computing state-point
  restores on behalf of the target]

- enable-undo/reverse: sets flag to request state-diff from target
  stub upon (step, next, etc.) commands.

- (step, next, etc.): as normal, but requests the state-diff from the
  target stub between successive command executions if reverse-execution
  flag is enabled. (This may also be supported without target stub support
  for state-diff, as GDB has direct access to both the target's machine
  state, and memory state; although target stubs may likely be capable
  of more efficient diff's if they are capable of tracking memory updates
  more efficiently than simply looking after the fact.)

- undo/reverse: undoes/reverses the previously issued command, by
  un-diff'ing the present machine and memory state with the previously
  returned diff. (which is likely sufficient and substantially more time
  and resource efficient than attempting to otherwise effectively
  single-step record all intervening individual instruction execution
  diff's, which could also be enabled if desired, although likely not
  necessary in general.)

Basic Target stub facilities to improve reverse execution efficiently:

- state-diff: the target returns the diff between the target's present
  state and it's previous state, which may be used if available in lieu
  of GDB directly calculating machine and memory state diffs, but would
  likely only be substantially more efficient if the target stub were
  capable of more efficiently tracking and accumulating diffs by directly
  monitoring memory state changes, rather than determining them after
  the fact, as may be done likely efficiently by a target simulator and
  then simply communicated by publishing the cumulative diffs as requested
  by GDB; which seems nice and simple, and minimally invasive.)

Re: [discuss] Support for reverse-execution

[Johan Rydberg]

Daniel Jacobowitz wrote:

> Johan, when I sketched out some algorithms for implementing these
> commands, I got the feeling that this was not a good way to do it.
> There are just too many ways to jump, and they can be pretty tricky to
> recognize on some architectures.  PowerPC is easy, but it's a little
> more complicated to disassemble starting from the end of an instruction
> on ia32.  Here's another one that requires absolutely no target support:
 > [...]

Yes, I'm well aware of this.

 > [...]
> i.e. build reverse-next on top of reverse-finish.  reverse-finish
> should take you to the intermediate caller in a tail call situation,
> not to the previous frame on the stack.

This approach has also crossed my mind, and minimizing the need for
target dependent code is worthwhile goal.  I'll see if I can hack
something up during the weekend.  I guess the changes should not be
that big.

~j

Re: [discuss] Support for reverse-execution

[Vladimir Prus]

Michael Snyder wrote:

> I'd like to start adding some commands to gdb to support targets
> that can perform reverse execution (eg. stepping backwards).
> This concept has been around for a number of years now, and I
> have access to a target (the Simics simulator from Virtutech)
> that does it quite handily.
> 
> I propose we add something like the following commands
> (names open to discussion):
> 
> reverse-continue -- start executing backwards until something
> interesting happens (most likely hitting a breakpoint).
> 
> reverse-stepi -- "un-execute" the previous instruction.
> 
> reverse-step -- "un-execute" the previous source line.
> 
> reverse-finish or "un-call" -- proceed backward until
> the current function is about to be called by its caller.
> 
> reverse-until... etc.

Would not it be better to have a single "reverse" command which puts the
debugger in "reverse" mode -- making step/stepi/next/nexti go backward.

This might be handier for UI -- after all "step" can be abbreviated as 's',
but reverse-step can't be abbreviated. This might be better in GUI too --
instead of doubling the number of "step" commands you'd have a single
"gear" switch, that can be in either "forward" or "reverse" position. 

- Volodya

Re: [discuss] Support for reverse-execution

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

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

They don't have to.  We have "s" as alias of "step" even though strictly
speaking it is ambigous (we have many commands starting with "s").

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Johan Rydberg <jrydberg@virtutech.com>, dan@shearer.org,
> 	gdb@sources.redhat.com
> Date: Fri, 20 May 2005 13:37:48 +0200
> 
> > "Go backwards until the program reaches the source line before the
> > current one."
> 
> The beginning or any part of the source line?

That's an interesting subtle point.  At first I wanted to say "the
former", but then I remembered the issue with moving a word forward
and backward in editors.  With some editors, such as Emacs,
forward-word ends up one character _before_ the beginning of the next
word, while backward-word ends up on the first character of the
previous word.  Other editors end up on the first character of a word
with either forward or backward movement.

So it could make sense for GDB to stop at the _last_ instruction of
the previous source line when we move backwards by lines.  The
question is, will this be useful for the user.  I'm not sure; perhaps
they will want to skip all the code of the line and stop before its
first instrcution, like "next" does.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Fri, 20 May 2005 09:13:48 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Johan Rydberg <jrydberg@virtutech.com>, dan@shearer.org,
> 	gdb@sources.redhat.com
> 
> > > +  add_com ("rnext", class_run, rnext_command,
> > > +           "Step program until it reaches the previous source line.\n\
> > 
> > "Go backwards until the program reaches the source line before the
> > current one."
> 
> Johan used previous, you used backwards; let's figure out what we're
> calling the commands first :-P

There's no connection between the doc strings and the discussion about
the command names.  I didn't use "backwards" instead of "previous", I
used it instead of "Step program".  That's because "step intil you
reach the previous source line" does not say explicitly enough that we
go backwards.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

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

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Fri, 20 May 2005 14:22:22 +0200
> From: Johan Rydberg <jrydberg@virtutech.com>
> Cc: dan@shearer.org, gdb@sources.redhat.com
> 
> (1)  foo (i);
>       0:   80 7f 00 08     lwz     r3,8(r31)
>       4:   48 00 00 01     bl      X <foo>
>       8:                   nop
> (2)  i = 0;
>       c:   38 00 00 00     li      r0,0
>      10:   90 1f 00 08     stw     r0,8(r31)
> 
> <foo>:
>      ....
>      4c:   4e 80 00 20     blr
> 
> You start with PC = c, and single steps backwards.  You end up on
> the nop-insn.  This is inside the single step range of line 1. So
> you single step another instruction backwards, and suddenly you
> stop at PC = 4c

I guess I don't understand how backwards movement works, because I
thought stepping backwards over the branch instruction does _not_ take
the branch, but rather rewinds the machine state to what it was before
the branch instruction.

Anyway, thanks for the explanations.

> >>+   add_com_alias ("rn", "rnext", class_run, 1);
> > 
> > Do we want another alias called "previous"?
> 
> I think so, and maybe also "prev" and/or "pre".

The additional aliases won't be necessary, since they both are
unambiguous abbreviations of "previous".  So they will work even if we
don't define them as aliases.

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 03:36:23PM +0200, Fabian Cenedese wrote:
> I followed this thread more out of curiosity than really need for this feature.
> That doesn't mean that we still couldn't use it one day :)
> 
> I wondered though if this stepping backwards was more than just a simple
> setting of the program counter. If I step back over a i++, will it also get
> decremented? Or flags, they can't possibly be restored to what they
> were before e.g. a comparison, not without keeping a history. So these
> r-commands are merely other variants of "set next instruction", possibly
> with creating/releasing stack frames but without adjusting values according
> to the stepped over commands. Is this correct?

No, that's not correct.  That's why the only target that supports this
at the moment is a simulator; it actually undoes the instructions and
allows them to replay.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Fabian Cenedese]

>Of course it's possible that you enter the previous line in the middle:
>
>=
>        line 1
>label:  line 1 some more
>        line 1 a bit more
>=
>PC:     line 2
>        line 2
>
>I think the way to do this is to take advantage of the fact that
>reversible targets are generally (always? too early to tell perhaps)
>going to be repeatable.  We can single-step backwards once, enter line
>1, single step backwards again, still in line 1, single-step backwards
>again, we've gone too far, single-step forwards.  Or, we could use a
>temporary bookmark.  Single-step backwards once, enter line 1, place
>bookmark, single-step backwards again, good, update bookmark.  Again,
>oops we're somewhere else, jump to bookmark and report a stop at label.

I followed this thread more out of curiosity than really need for this feature.
That doesn't mean that we still couldn't use it one day :)

I wondered though if this stepping backwards was more than just a simple
setting of the program counter. If I step back over a i++, will it also get
decremented? Or flags, they can't possibly be restored to what they
were before e.g. a comparison, not without keeping a history. So these
r-commands are merely other variants of "set next instruction", possibly
with creating/releasing stack frames but without adjusting values according
to the stepped over commands. Is this correct?

Thanks

bye  Fabi

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 02:22:22PM +0200, Johan Rydberg wrote:
> >>+extern enum step_direction_kind step_direction; 
> >
> >Yuk! a global variable!
> 
> I though it was OK since other variables in this context
> are global, such as step_range_start and step_frame_id.

This code goes back a long, long way.  We're trying to improve it,
which means not adding more globals :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 01:37:48PM +0200, Andreas Schwab wrote:
> The beginning or any part of the source line?  While the latter is easy to
> determine (just step until the source line changes), the former is not
> very well defined, since the code for a source line can be intermixed with
> code from other source lines.  On the other hand, just stepping until the
> source line changes is not very useful, since in extreme case you'll just
> step back a single insn if the previous command was a forward step and you
> won't really undo much of this step.

I suspect that the best we can do is back to the beginning of the
previous fragment of a source line; step backwards until your PC
matches the start of an entry in the line table.

We need a coherent story for presenting fragmented lines to the user,
but we don't have one - in either direction.  That'll be as good as
what we do going forwards.

Of course it's possible that you enter the previous line in the middle:

=
	line 1
label:	line 1 some more
	line 1 a bit more
=
PC:	line 2
	line 2

I think the way to do this is to take advantage of the fact that
reversible targets are generally (always? too early to tell perhaps)
going to be repeatable.  We can single-step backwards once, enter line
1, single step backwards again, still in line 1, single-step backwards
again, we've gone too far, single-step forwards.  Or, we could use a
temporary bookmark.  Single-step backwards once, enter line 1, place
bookmark, single-step backwards again, good, update bookmark.  Again,
oops we're somewhere else, jump to bookmark and report a stop at label.

Or implement both in case some target supports reverse execution
without bookmarks.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

Disclaimer: I have not looked at the code at all; I want to get the
copyright assignment rolling first.

On Fri, May 20, 2005 at 01:32:47PM +0300, Eli Zaretskii wrote:
> > To implement "rnext" I had to add a new target-specific function that
> > tries to figure out the address of the call instruction based on the
> > last executed instruction and the instruction to be executed, IF the
> > current instruction can be identified as a return insn.

Johan, when I sketched out some algorithms for implementing these
commands, I got the feeling that this was not a good way to do it.
There are just too many ways to jump, and they can be pretty tricky to
recognize on some architectures.  PowerPC is easy, but it's a little
more complicated to disassemble starting from the end of an instruction
on ia32.  Here's another one that requires absolutely no target support:
  - Detect reverse-step into a function
  - Set breakpoints at all entry points of the function; GDB doesn't
    support multiple entry points yet, really, so a breakpoint at
    the first instruction and a big fat comment is all this takes.
  - When you hit an entry point breakpoint, reverse-step once more.
  - If you have entered a different function, for instance via a
    reversed tail call, and you can still see the desired frame
    on the stack, then repeat.

i.e. build reverse-next on top of reverse-finish.  reverse-finish
should take you to the intermediate caller in a tail call situation,
not to the previous frame on the stack.

Of course neither algorithm is robust in the case of stray jumps. 
Bookmarks and single-steps for that are the best we're going to get.

> > +  add_com ("rnext", class_run, rnext_command,
> > +           "Step program until it reaches the previous source line.\n\
> 
> "Go backwards until the program reaches the source line before the
> current one."

Johan used previous, you used backwards; let's figure out what we're
calling the commands first :-P

> > +   add_com_alias ("rn", "rnext", class_run, 1);
> 
> Do we want another alias called "previous"?

I have no objection.

> I'd prefer that target_resume accepted the direction argument.  Is
> there something that I'm missing that makes this hard or impossible?

It should either be an argument, or a separate target hook as Michael
proposed.  No existing target supports it, so it would save us updating
all targets to reject it.  Which is just mechanical, so I don't feel
strongly either way.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 01:51:31PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 19 May 2005 09:41:50 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Michael Snyder <msnyder@redhat.com>, gdb@sources.redhat.com
> > 
> > > Not "reverse", "backwards" or "back".  "Reverse" will become ambiguous
> > > once we have two possible directions.
> > 
> > Actually I think "reverse" is a more logical term.  Drivers don't
> > seem to get confused when they put a car into reverse
> 
> One can learn anything, given enough practice.  So the fact drivers
> can get accustomed to this doesn't mean it won't be harder for GDB
> users.  Most people don't use GDB as frequently as they drive cars.

But many GDB users drive cars :-)  Anyway let's not go there.  You
think it is ambiguous; I disagree.

> > 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 think that
auto-repeat when you hit return at a GDB prompt is all we want to have,
and we already have that.

> > "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.  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.  And we aren't limited to one name for things!  We could
add "prev" as an alias to "next" if you like that.

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

We could use "backwards" for everything.  Those mostly sound right,
except that backwards has some unfortunate connotations.  I think
that advance and finish come out as particularly odd:
  backwards-continue, backwards-step, backwards-next, backwards-stepi,
  backwards-nexti, backwards-until, backwards-advance, backwards-finish

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

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Johan Rydberg]

Eli Zaretskii wrote:

>>What I have done is add a new variable, step_direction, that can either
>>be STEP_DIR_FORWARD or STEP_DIR_REVERSE. 
> 
> I'd prefer STEP_FORWARD and STEP_BACKWARD.

Ok.

>>To implement "rnext" I had to add a new target-specific function that
>>tries to figure out the address of the call instruction based on the
>>last executed instruction and the instruction to be executed, IF the
>>current instruction can be identified as a return insn.
>  
> Sorry, I'm confused.  Isn't it right that if I'm stepping backwards
> through code such as this:
> 
>     i += 1;
>     foo (i);
>   =>i = 0;
> 
> where "=>" shows the current source line, then typing `rnext' once
> will get me to this:
> 
>     i += 1;
>   =>foo (i);
>     i = 0;
> 
> which means I'm now before the CALL insn that calls `foo'?  If so,
> what ``return insn'' were you talking about?  If it's the return
> instruction that returns from `foo', then that insn is inside the code
> generatedfor `foo', which GDB won't see.  What am I missing?

When you're single stepping backwards you can end up almost anywhere
in the code.  Take this scenario (in pseudo-PPC-assembler):

(1)  foo (i);
      0:   80 7f 00 08     lwz     r3,8(r31)
      4:   48 00 00 01     bl      X <foo>
      8:                   nop
(2)  i = 0;
      c:   38 00 00 00     li      r0,0
     10:   90 1f 00 08     stw     r0,8(r31)

<foo>:
     ....
     4c:   4e 80 00 20     blr

You start with PC = c, and single steps backwards.  You end up on
the nop-insn.  This is inside the single step range of line 1. So
you single step another instruction backwards, and suddenly you
stop at PC = 4c, which is far outside the stepping range.  To detect
if this was due to a "return from subroutine" you inspect the current
instruction, blr, and if it happens to be return insn you can deduct
the address of the call insn that called "foo". Since PowerPC does
not have any delay slots, it's "safe" to assume that the insn _before_
the LAST stop_pc (== prev_pc) is the call insn.

So to skip the subroutine call, you set a breakpoint on 0x4
(prev_pc - 4 = 8 - 4 = 4) and do a reverse-continue.  When the
breakpoint hits, you continue stepping until you reach the start
of the stepping range.


>>+  add_com ("rnext", class_run, rnext_command,
>>+           "Step program until it reaches the previous source line.\n\
> 
> "Go backwards until the program reaches the source line before the
> current one."

Ok.

> 
>>+   add_com_alias ("rn", "rnext", class_run, 1);
> 
> Do we want another alias called "previous"?

I think so, and maybe also "prev" and/or "pre".

>>+extern enum step_direction_kind step_direction; 
> 
> Yuk! a global variable!

I though it was OK since other variables in this context
are global, such as step_range_start and step_frame_id.

>>+      if (step_direction == STEP_DIR_FORWARD)
>>+	target_resume (resume_ptid, step, sig);
>>+      else
>>+	{
>>+	  target_reverse (resume_ptid, step);
>>+	} 
> 
> I'd prefer that target_resume accepted the direction argument.  Is
> there something that I'm missing that makes this hard or impossible?

I don't think so.  You just need to update more targets, though.

~j

Re: [discuss] Support for reverse-execution

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Thu, 19 May 2005 15:00:52 +0200
>> From: Johan Rydberg <jrydberg@virtutech.com>
>> Cc: gdb@sources.redhat.com
>> 
>> +  add_com ("rnext", class_run, rnext_command,
>> +           "Step program until it reaches the previous source line.\n\
>
> "Go backwards until the program reaches the source line before the
> current one."

The beginning or any part of the source line?  While the latter is easy to
determine (just step until the source line changes), the former is not
very well defined, since the code for a source line can be intermixed with
code from other source lines.  On the other hand, just stepping until the
source line changes is not very useful, since in extreme case you'll just
step back a single insn if the previous command was a forward step and you
won't really undo much of this step.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Thu, 19 May 2005 09:41:50 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Michael Snyder <msnyder@redhat.com>, gdb@sources.redhat.com
> 
> > Not "reverse", "backwards" or "back".  "Reverse" will become ambiguous
> > once we have two possible directions.
> 
> Actually I think "reverse" is a more logical term.  Drivers don't
> seem to get confused when they put a car into reverse

One can learn anything, given enough practice.  So the fact drivers
can get accustomed to this doesn't mean it won't be harder for GDB
users.  Most people don't use GDB as frequently as they drive cars.

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

> "back-continue" and "back-next" just don't sound right.

Neither does "reverse-next".  Perhaps we should use "prev" instead.

> Whichever name we settle on let's be consistent - if we use "reverse"
> for the commands and documentation, we should use if for the target
> hook too.

Yes.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Thu, 19 May 2005 10:52:54 +0930
> From: Dan Shearer <dan@shearer.org>
> 
> Imagine two new gdb commands, get-bookmark and goto-bookmark.
> get-bookmark asks the simulator for a token which uniquely identifies
> the current state of the system. goto-bookmark gives a token back to the
> simulator and asks the simulator to load system state as it was at the
> time of the bookmark. The token is an arbitary number that makes sense
> to the particular simulator. Some might count in clock cycles, others in
> milliseconds or maybe the number of the checkpoint that corresponds to
> the state at that time. All gdb knows about is the value of the
> bookmark.
> 
> This gives a gdb user the capability to explore alternative futures
> without a complicated interface. A sequence might be get-bookmark,
> change a value, run for ten seconds. Break, goto-bookmark, try another
> value and run for ten seconds. Like an infinite rewind-replay facility,
> very helpful when part of the pain is getting the circumstances just
> right for the bug to appear.
> 
> It would be an interesting discussion to see how bookmarks could be
> incorporated into the gdb framework.

Sounds like a very useful feature.  However, I think we need to
support giving meaningful names to bookmarks, since a (more or less
arbitrary) number used by the target is going to lack any mnemonic
value.

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> Date: Thu, 19 May 2005 15:00:52 +0200
> From: Johan Rydberg <jrydberg@virtutech.com>
> Cc: gdb@sources.redhat.com
> 
> Here's a patch against CVS that implements the following commands:
> 
>    - rstep, rstepi
>    - rnext, rnexti
> 
> The obvious commands "rcontinue" and "rfinished" are not yet
> implemented, and therefor not included in this patch.  The command
> names are of course up for discussion.

I don't mind these names; reverse-next etc. seem awkward, but rnext
etc. are okay, I think.  However, see my other comments in response to
Daniel.

> What I have done is add a new variable, step_direction, that can either
> be STEP_DIR_FORWARD or STEP_DIR_REVERSE.

I'd prefer STEP_FORWARD and STEP_BACKWARD.

> To implement "rnext" I had to add a new target-specific function that
> tries to figure out the address of the call instruction based on the
> last executed instruction and the instruction to be executed, IF the
> current instruction can be identified as a return insn.

Sorry, I'm confused.  Isn't it right that if I'm stepping backwards
through code such as this:

    i += 1;
    foo (i);
  =>i = 0;

where "=>" shows the current source line, then typing `rnext' once
will get me to this:

    i += 1;
  =>foo (i);
    i = 0;

which means I'm now before the CALL insn that calls `foo'?  If so,
what ``return insn'' were you talking about?  If it's the return
instruction that returns from `foo', then that insn is inside the code
generatedfor `foo', which GDB won't see.  What am I missing?

> +  add_com ("rnext", class_run, rnext_command,
> +           "Step program until it reaches the previous source line.\n\

"Go backwards until the program reaches the source line before the
current one."

> +   add_com_alias ("rn", "rnext", class_run, 1);

Do we want another alias called "previous"?

> +extern enum step_direction_kind step_direction;

Yuk! a global variable!

> +      if (step_direction == STEP_DIR_FORWARD)
> +	target_resume (resume_ptid, step, sig);
> +      else
> +	{
> +	  target_reverse (resume_ptid, step);
> +	}

I'd prefer that target_resume accepted the direction argument.  Is
there something that I'm missing that makes this hard or impossible?

Re: [discuss] Support for reverse-execution

[Johan Rydberg]

Michael Snyder wrote:

>> You used rc, Johan used bc.  It should be consistent with the command
>> names. 
>
> Johan?  Is there a conversation that I missed?

No.  I just choose "bc" instead of "rc" because our GDB stub used "r" for
'reset' -- but I can't seem to find that "r" is used in remote.c, so I guess
our code is at fault.

But as I stated earlier, the patch should been seen as a proof-of-concept.
Nothing is written in stone here.

~j

Re: [discuss] Support for reverse-execution

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Fri, May 13, 2005 at 09:19:17AM +0300, Eli Zaretskii wrote:
> 
>>>I propose we add something like the following commands
>>>(names open to discussion):
>>>
>>>reverse-continue -- start executing backwards until something
>>>interesting happens (most likely hitting a breakpoint).
>>>
>>>reverse-stepi -- "un-execute" the previous instruction.
>>>
>>>reverse-step -- "un-execute" the previous source line.
>>>
>>>reverse-finish or "un-call" -- proceed backward until 
>>>the current function is about to be called by its caller.
>>>
>>>reverse-until... etc.
>>
>>Not "reverse", "backwards" or "back".  "Reverse" will become ambiguous
>>once we have two possible directions.
> 
> 
> Actually I think "reverse" is a more logical term.  Drivers don't
> seem to get confused when they put a car into reverse, which is a
> natural parallel.  The program doesn't have a persistant direction.
> If it's stopped, "continue" will always move forwards in time
> and "reverse-continue" will always move backwards.
> 
> "back-step" is kind of appealing, but "back-continue" and "back-next"
> just don't sound right.  I suppose we could use "continue-backwards"?
> 
> I would just have called the command rcontinue, but reverse-continue is
> fine with me too; either way we'll hopefully offer abbreviations, like
> "c" and "si".

Yeah, I was thinking of "reverse-continue" as the long-form,
and anticipating one or more abbreviated aliases such as
rcontinue or rc.


>>>Along with these commands, we would need at least two new
>>>remote-protocol messages: "rc" for reverse-continue, and "rs" 
>>>for reverse-stepi.  I think all of the above user commands could
>>>be implemented on these primatives.  Obviously if the remote
>>>target doesn't understand these primatives, the user command 
>>>would error.
> 
> 
> You used rc, Johan used bc.  It should be consistent with the command
> names. 

Johan?  Is there a conversation that I missed?


> I wish one of you had noticed vCont though, at least as an
> example :-)

Thanks for bringing it to my (our) attention.

> [threads]

Yeah, as I currently think of it, reverse execution would
deterministically reiterate (or de-iterate) what happened
before -- therefore you cannot expect to change the course
of the execution while running in reverse.  Any interferance
with thread scheduling would change the outcome (income?)

If you first back up, and then shift into forward again,
that's another story...

> I'm not dead set on this idea; the benefits of consistency are pretty
> small in this case and the thread-specific expressive power of vCont is
> not obviously useful for reverse execution.  However I think a query
> packet is still wise.  This allows a front end to modify its interface
> based on whether the target supports reverse execution without having
> to try it.

My thinking was (admittedly old-school): just try it, and if the
target doesn't understand it, then report accordingly to the user.
But I'm totally open to other suggestions.


>>>Finally, we'd need a new entry for the target vector --
>>>something like "to_resume_backwards".  If the target vector
>>>doesn't export this method, the user command would error.
> 
> 
> Whichever name we settle on let's be consistent - if we use "reverse"
> for the commands and documentation, we should use if for the target
> hook too.

Sure.

>>Please don't forget the manual changes for these features.
> 
> 
> Definitely!

Sure.  ;-)

Re: [discuss] Support for reverse-execution

[Johan Rydberg]

Daniel Jacobowitz wrote:

> Do you, and Virtutech, have copyright papers filed with the FSF?  The
> GNU shell server is down at the moment, so I can't check myself.  It
> would be best if we don't look at patches until that's taken care of.

No.  Can you send me the form, please?

~j

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Fri, May 13, 2005 at 09:19:17AM +0300, Eli Zaretskii wrote:
> > I propose we add something like the following commands
> > (names open to discussion):
> > 
> > reverse-continue -- start executing backwards until something
> > interesting happens (most likely hitting a breakpoint).
> > 
> > reverse-stepi -- "un-execute" the previous instruction.
> > 
> > reverse-step -- "un-execute" the previous source line.
> > 
> > reverse-finish or "un-call" -- proceed backward until 
> > the current function is about to be called by its caller.
> > 
> > reverse-until... etc.
> 
> Not "reverse", "backwards" or "back".  "Reverse" will become ambiguous
> once we have two possible directions.

Actually I think "reverse" is a more logical term.  Drivers don't
seem to get confused when they put a car into reverse, which is a
natural parallel.  The program doesn't have a persistant direction.
If it's stopped, "continue" will always move forwards in time
and "reverse-continue" will always move backwards.

"back-step" is kind of appealing, but "back-continue" and "back-next"
just don't sound right.  I suppose we could use "continue-backwards"?

I would just have called the command rcontinue, but reverse-continue is
fine with me too; either way we'll hopefully offer abbreviations, like
"c" and "si".

> > Along with these commands, we would need at least two new
> > remote-protocol messages: "rc" for reverse-continue, and "rs" 
> > for reverse-stepi.  I think all of the above user commands could
> > be implemented on these primatives.  Obviously if the remote
> > target doesn't understand these primatives, the user command 
> > would error.

You used rc, Johan used bc.  It should be consistent with the command
names.  I wish one of you had noticed vCont though, at least as an
example :-)

`vCont'[;ACTION[`:'TID]]... -- extended resume
     Resume the inferior.  Different actions may be specified for each
     thread.  If an action is specified with no TID, then it is applied
     to any threads that don't have a specific action specified; if no
     default action is specified then other threads should remain
     stopped.  Specifying multiple default actions is an error;
     specifying no actions is also an error.  Thread IDs are specified
     in hexadecimal.  Currently supported actions are:

Hmm, thinking about this some more, maybe not such a bright idea. The
documentation would need some clarification, since even if we someday
have a simulator which both supports reverse execution and presents a
view of multiple threads (the implications are dizzying) I'm sure it
will be strictly limited in how you can back up the program.  Backing
up one thread while running another forwards, or even while leaving
another stopped, doesn't make sense - it creates a view of execution
which never occurred in the previous run.  However, there are still two
advantages to vCont: consistency, and a pre-existing query packet,
vCont?.

I'm not dead set on this idea; the benefits of consistency are pretty
small in this case and the thread-specific expressive power of vCont is
not obviously useful for reverse execution.  However I think a query
packet is still wise.  This allows a front end to modify its interface
based on whether the target supports reverse execution without having
to try it.

> > Finally, we'd need a new entry for the target vector --
> > something like "to_resume_backwards".  If the target vector
> > doesn't export this method, the user command would error.

Whichever name we settle on let's be consistent - if we use "reverse"
for the commands and documentation, we should use if for the target
hook too.

> Please don't forget the manual changes for these features.

Definitely!

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz]

On Thu, May 19, 2005 at 03:00:52PM +0200, Johan Rydberg wrote:
> Here's a patch against CVS that implements the following commands:
> 
>   - rstep, rstepi
>   - rnext, rnexti

Do you, and Virtutech, have copyright papers filed with the FSF?  The
GNU shell server is down at the moment, so I can't check myself.  It
would be best if we don't look at patches until that's taken care of.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [discuss] Support for reverse-execution

[Johan Rydberg]

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

Dan Shearer wrote:

> Johan Rydberg, a developer at Virtutech, has got some patches against
> 6.3 (for discussion only) that he'll be sending along to this list. I
> want to bring up bookmarks for discussion, a topic that isn't yet
> addressed by his patches.
> 
> First, what is addressed: Johan has implemented the reverse instructions
> rstep, rstepi, rnext and rnexti for PowerPC, Sparc and Sparc64 targets.
 > [...]

Here's a patch against CVS that implements the following commands:

   - rstep, rstepi
   - rnext, rnexti

The obvious commands "rcontinue" and "rfinished" are not yet
implemented, and therefor not included in this patch.  The command
names are of course up for discussion.

Other things that is missing from the patch:

   - Error handling.  GDB will not complain if the remote stub does
     not implement reverse execution.

   - Documentaton of the commands.

   - Some corner cases are not handled yet.

   - Mechanism for working with bookmarks.

What I have done is add a new variable, step_direction, that can either
be STEP_DIR_FORWARD or STEP_DIR_REVERSE.  A new target vector has also
been added; to_reverse.  The remote protocol has been extended with two
new functions: "bs" and "bc"

To implement "rnext" I had to add a new target-specific function that
tries to figure out the address of the call instruction based on the
last executed instruction and the instruction to be executed, IF the
current instruction can be identified as a return insn.

This patch should not been seen as a straight forward contribution, but
as a proof-of-concept implementation.  A lot of things could probably
be done better, and more in the "GDB-way", so any input is will
appreciated.

Currently the patch only works for PowerPC and SPARC targets, though
I plan to add support for a few more targets in the near future.

Obviously it is a bit hard to test without access to a reversible target
but  we are working on changing that in the next month or so (Dan has
more  information on that.)

Thanks,
Johan

[-- Attachment #2: gdb-reverse-1.patch --]
[-- Type: text/x-patch, Size: 19492 bytes --]

Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.361
diff -u -r1.361 gdbarch.sh
--- gdbarch.sh	14 May 2005 06:07:41 -0000	1.361
+++ gdbarch.sh	19 May 2005 12:57:30 -0000
@@ -591,6 +591,10 @@
 v:=:int:frame_red_zone_size
 #
 m::CORE_ADDR:convert_from_func_ptr_addr:CORE_ADDR addr, struct target_ops *targ:addr, targ::convert_from_func_ptr_addr_identity::0
+
+# When running backwards it's needed to calculate the address of the
+# call instruction when the single stepper hits a return insn.
+f:=:int:call_insn_from_return_addr:CORE_ADDR pc, CORE_ADDR prev_pc, CORE_ADDR *call_pc:pc, prev_pc, call_pc::0:
 # On some machines there are bits in addresses which are not really
 # part of the address, but are used by the kernel, the hardware, etc.
 # for special purposes.  ADDR_BITS_REMOVE takes out any such bits so
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.137
diff -u -r1.137 infcmd.c
--- infcmd.c	12 May 2005 20:21:17 -0000	1.137
+++ infcmd.c	19 May 2005 12:57:30 -0000
@@ -100,7 +100,7 @@
 
 static void jump_command (char *, int);
 
-static void step_1 (int, int, char *);
+static void step_1 (int, int, char *, enum step_direction_kind);
 static void step_once (int skip_subroutines, int single_inst, int count);
 static void step_1_continuation (struct continuation_arg *arg);
 
@@ -579,13 +579,39 @@
 
   proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);
 }
+
+\f
+static void
+rstep_command (char *count_string, int from_tty)
+{
+  step_1 (0, 0, count_string, STEP_DIR_REVERSE);
+}
+
+static void
+rstepi_command (char *count_string, int from_tty)
+{
+  step_1 (0, 1, count_string, STEP_DIR_REVERSE);
+}
+
+static void
+rnext_command (char *count_string, int from_tty)
+{
+  step_1 (1, 0, count_string, STEP_DIR_REVERSE);
+}
+
+static void
+rnexti_command (char *count_string, int from_tty)
+{
+  step_1 (1, 1, count_string, STEP_DIR_REVERSE);
+}
+
 \f
 /* Step until outside of current statement.  */
 
 static void
 step_command (char *count_string, int from_tty)
 {
-  step_1 (0, 0, count_string);
+  step_1 (0, 0, count_string, STEP_DIR_FORWARD);
 }
 
 /* Likewise, but skip over subroutine calls as if single instructions.  */
@@ -593,7 +619,7 @@
 static void
 next_command (char *count_string, int from_tty)
 {
-  step_1 (1, 0, count_string);
+  step_1 (1, 0, count_string, STEP_DIR_FORWARD);
 }
 
 /* Likewise, but step only one instruction.  */
@@ -601,13 +627,13 @@
 void
 stepi_command (char *count_string, int from_tty)
 {
-  step_1 (0, 1, count_string);
+  step_1 (0, 1, count_string, STEP_DIR_FORWARD);
 }
 
 void
 nexti_command (char *count_string, int from_tty)
 {
-  step_1 (1, 1, count_string);
+  step_1 (1, 1, count_string, STEP_DIR_FORWARD);
 }
 
 static void
@@ -617,7 +643,8 @@
 }
 
 static void
-step_1 (int skip_subroutines, int single_inst, char *count_string)
+step_1 (int skip_subroutines, int single_inst, char *count_string,
+	enum step_direction_kind direction)
 {
   int count = 1;
   struct frame_info *frame;
@@ -659,6 +686,7 @@
       for (; count > 0; count--)
 	{
 	  clear_proceed_status ();
+	  step_direction = direction;
 
 	  frame = get_current_frame ();
 	  if (!frame)		/* Avoid coredump here.  Why tho? */
@@ -712,6 +740,8 @@
      and handle them one at the time, through step_once(). */
   else
     {
+      gdb_assert (0);
+
       if (target_can_async_p ())
 	step_once (skip_subroutines, single_inst, count);
     }
@@ -2082,6 +2112,16 @@
 Argument N means do this N times (or till program stops for another reason)."));
   add_com_alias ("ni", "nexti", class_alias, 0);
 
+  add_com ("rstepi", class_run, rstepi_command,
+ 	   "Reverse one instruction, but proceed through subroutine calls.\n\
+Argument N means do this N times (or till program stops for another reason).");
+  add_com_alias ("rsi", "rstepi", class_alias, 0);
+ 
+  add_com ("rnexti", class_run, rnexti_command,
+ 	   "Reverse one instruction, skipping subroutine calls.\n\
+Argument N means do this N times (or till program stops for another reason).");
+  add_com_alias ("rni", "rnexti", class_run, 1);
+ 
   add_com ("finish", class_run, finish_command, _("\
 Execute until selected stack frame returns.\n\
 Upon return, the value returned is printed and put in the value history."));
@@ -2100,6 +2140,16 @@
 Argument N means do this N times (or till program stops for another reason)."));
   add_com_alias ("s", "step", class_run, 1);
 
+  add_com ("rstep", class_run, rstep_command,
+	   "Reverse program until it reaches a different source line.\n\
+Argument N means do this N times (or till program stops for another reason).");
+  add_com_alias ("rs", "rstep", class_run, 1);
+ 
+  add_com ("rnext", class_run, rnext_command,
+           "Step program until it reaches the previous source line.\n\
+Argument N means do this N times (or till program stops for another reason).");
+   add_com_alias ("rn", "rnext", class_run, 1);
+
   c = add_com ("until", class_run, until_command, _("\
 Execute until the program reaches a source line greater than the current\n\
 or a specified location (same args as break command) within the current frame."));
Index: inferior.h
===================================================================
RCS file: /cvs/src/src/gdb/inferior.h,v
retrieving revision 1.71
diff -u -r1.71 inferior.h
--- inferior.h	14 May 2005 06:07:42 -0000	1.71
+++ inferior.h	19 May 2005 12:57:30 -0000
@@ -373,6 +373,17 @@
 
 extern enum step_over_calls_kind step_over_calls;
 
+/* STEP_DIR_FORWARD means normal execution,
+   STEP_DIR_REVERSE means going back in time.  */
+
+enum step_direction_kind
+  {
+    STEP_DIR_FORWARD,
+    STEP_DIR_REVERSE
+  };
+
+extern enum step_direction_kind step_direction;
+
 /* If stepping, nonzero means step count is > 1
    so don't print frame next time inferior stops
    if it stops due to stepping.  */
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.201
diff -u -r1.201 infrun.c
--- infrun.c	12 May 2005 20:21:17 -0000	1.201
+++ infrun.c	19 May 2005 12:57:32 -0000
@@ -247,6 +247,10 @@
 
 static struct symbol *step_start_function;
 
+/* Direction of which the execution is heading.  */
+
+enum step_direction_kind step_direction;
+
 /* Nonzero if we are expecting a trace trap and should proceed from it.  */
 
 static int trap_expected;
@@ -509,7 +513,6 @@
     }
 }
 
-
 /* Resume the inferior, but allow a QUIT.  This is useful if the user
    wants to interrupt some lengthy single-stepping operation
    (for child processes, the SIGINT goes to the inferior, and so
@@ -620,13 +623,19 @@
 	  if (step && breakpoints_inserted && breakpoint_here_p (read_pc ()))
 	    step = 0;
 	}
-      target_resume (resume_ptid, step, sig);
+
+      if (step_direction == STEP_DIR_FORWARD)
+	target_resume (resume_ptid, step, sig);
+      else
+	{
+	  target_reverse (resume_ptid, step);
+	}
     }
 
   discard_cleanups (old_cleanups);
 }
-\f
 
+\f
 /* Clear out all variables saying what to do when inferior is continued.
    First do this, then set the ones you want, then call `proceed'.  */
 
@@ -638,6 +647,7 @@
   step_range_end = 0;
   step_frame_id = null_frame_id;
   step_over_calls = STEP_OVER_UNDEBUGGABLE;
+  step_direction = STEP_DIR_FORWARD;
   stop_after_trap = 0;
   stop_soon = NO_STOP_QUIETLY;
   proceed_to_finish = 0;
@@ -2099,6 +2109,21 @@
         if (debug_infrun)
 	  fprintf_unfiltered (gdb_stdlog, "infrun: BPSTATE_WHAT_STEP_RESUME\n");
 
+        /* If stepping over functions calls while reversing we might
+           have to still continue running even if we hit the
+           breakpoint.  This to enable "prev" to step over recursive
+           calls.  */
+        if (step_over_calls == STEP_OVER_ALL
+            && step_direction == STEP_DIR_REVERSE
+            && (frame_id_inner (frame_unwind_id (get_current_frame ()), 
+                                step_frame_id)
+                || frame_id_eq (frame_unwind_id (get_current_frame ()), 
+                                step_frame_id)))
+          {
+	    keep_going (ecs);
+	    return;
+          }
+
 	if (step_resume_breakpoint == NULL)
 	  {
 	    step_resume_breakpoint =
@@ -2117,6 +2142,17 @@
 	    keep_going (ecs);
 	    return;
 	  }
+        /* If running backwards break out of this step-resume
+           breakpoint was set on the first insn in the line.  */
+
+        if (step_direction == STEP_DIR_REVERSE 
+            && stop_pc == step_range_start)
+          {
+            stop_step = 1;
+            print_stop_reason (END_STEPPING_RANGE, 0);
+            stop_stepping (ecs);
+            return;
+          }
 	break;
 
       case BPSTAT_WHAT_THROUGH_SIGTRAMP:
@@ -2268,7 +2304,7 @@
       return;
     }
 
-  if (step_resume_breakpoint)
+  if (step_resume_breakpoint && step_direction != STEP_DIR_REVERSE)
     {
       if (debug_infrun)
 	 fprintf_unfiltered (gdb_stdlog, "infrun: step-resume breakpoint\n");
@@ -2288,13 +2324,21 @@
       keep_going (ecs);
       return;
     }
-
+  
   /* If stepping through a line, keep going if still within it.
-
+     
      Note that step_range_end is the address of the first instruction
-     beyond the step range, and NOT the address of the last instruction
-     within it! */
-  if (stop_pc >= step_range_start && stop_pc < step_range_end)
+     beyond the step range, and NOT the address of the last
+     instruction within it!  Also, if running backwards, stop if we
+     hit the first instruction in the line. */
+  if (step_direction == STEP_DIR_REVERSE && stop_pc == step_range_start)
+    {
+      stop_step = 1;
+      print_stop_reason (END_STEPPING_RANGE, 0);
+      stop_stepping (ecs);
+      return;
+    }
+  else if (stop_pc >= step_range_start && stop_pc < step_range_end)
     {
       if (debug_infrun)
 	 fprintf_unfiltered (gdb_stdlog, "infrun: stepping inside range [0x%s-0x%s]\n",
@@ -2511,16 +2555,43 @@
 	}
       else
 	{
-	  /* Set a breakpoint at callee's return address (the address
-	     at which the caller will resume).  */
-	  insert_step_resume_breakpoint_at_frame (get_prev_frame (get_current_frame ()));
-	  keep_going (ecs);
-	  return;
+          if (step_direction == STEP_DIR_FORWARD)
+            {
+              /* Set a breakpoint at callee's return address (the
+                 address at which the caller will resume).  */
+              insert_step_resume_breakpoint_at_frame 
+                (get_prev_frame (get_current_frame ()));
+              keep_going (ecs);
+              return;
+            }
+          else
+            {
+              /* FIXME: gdb-reverse */
+              gdb_assert (0);
+            }
 	}
     }
 
   if (step_range_end == 1)
     {
+      CORE_ADDR call_pc;
+
+      /* For previ we must also check so we did not just end up inside
+         a subroutine.  */
+      if (step_direction == STEP_DIR_REVERSE 
+          && step_over_calls == STEP_OVER_ALL
+          && CALL_INSN_FROM_RETURN_ADDR (stop_pc, prev_pc, &call_pc))
+        {
+	  struct symtab_and_line sr_sal;
+
+	  init_sal (&sr_sal);
+	  sr_sal.pc = call_pc;
+
+	  insert_step_resume_breakpoint_at_sal (sr_sal, null_frame_id);
+          keep_going (ecs);
+          return;
+        }
+
       /* It is stepi or nexti.  We always want to stop stepping after
          one instruction.  */
       if (debug_infrun)
@@ -2563,6 +2634,32 @@
       return;
     }
 
+  if (step_direction == STEP_DIR_REVERSE 
+      && step_over_calls == STEP_OVER_ALL)
+    {
+      /* Going backwards we can make the assumption that if stop_pc is
+         not within the stepping range, prev_pc was the target of a
+         branch (insn that stop_pc points to).  If stop_pc is a return
+         instruction, and subroutine calls should be stepped over, do
+         it here.  It is also known that prev_pc was the last executed
+         insn, i.e., the target of the branch.  */
+      /* It has already been proven that stop_pc is not within the
+         stepping range.  */
+      CORE_ADDR call_pc;
+
+      if (CALL_INSN_FROM_RETURN_ADDR (stop_pc, prev_pc, &call_pc))
+        {
+	  struct symtab_and_line sr_sal;
+
+	  init_sal (&sr_sal);
+	  sr_sal.pc = call_pc;
+
+	  insert_step_resume_breakpoint_at_sal (sr_sal, step_frame_id);
+          keep_going (ecs);
+          return;
+        }
+    }
+
   /* We aren't done stepping.
 
      Optimize by setting the stepping range to the line.
@@ -2570,7 +2667,8 @@
      new line in mid-statement, we continue stepping.  This makes
      things like for(;;) statements work better.)  */
 
-  if (ecs->stop_func_end && ecs->sal.end >= ecs->stop_func_end)
+  if (ecs->stop_func_end && ecs->sal.end >= ecs->stop_func_end
+      && step_direction == STEP_DIR_FORWARD)
     {
       /* If this is the last line of the function, don't keep stepping
          (it would probably step us out of the function).
@@ -2621,7 +2719,7 @@
 }
 
 /* Are we in the middle of stepping?  */
-
+ 
 static int
 currently_stepping (struct execution_control_state *ecs)
 {
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.190
diff -u -r1.190 remote.c
--- remote.c	16 May 2005 16:36:24 -0000	1.190
+++ remote.c	19 May 2005 12:57:32 -0000
@@ -2617,6 +2617,26 @@
   if (target_is_async_p ())
     target_executing = 1;
 }
+
+/* Run in reverse.  */
+static int
+remote_reverse (ptid_t ptid, int step)
+{
+  struct remote_state *rs = get_remote_state ();
+  char *buf = alloca (rs->remote_packet_size);
+  int pid = PIDGET (ptid);
+  
+  /* All other supported resume packets do use Hc, so call set_thread.  */
+  if (pid == -1)
+    set_thread (0, 0);		/* run any thread */
+  else
+    set_thread (pid, 0);	/* run this thread */
+
+  strcpy (buf, step ? "bs" : "bc");
+  putpkt (buf);
+
+  return 0;
+}
 \f
 
 /* Set up the signal handler for SIGINT, while the target is
@@ -5413,6 +5433,7 @@
   remote_ops.to_has_registers = 1;
   remote_ops.to_has_execution = 1;
   remote_ops.to_has_thread_control = tc_schedlock;	/* can lock scheduler */
+  remote_ops.to_reverse = remote_reverse;
   remote_ops.to_magic = OPS_MAGIC;
 }
 
Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.240
diff -u -r1.240 rs6000-tdep.c
--- rs6000-tdep.c	1 May 2005 19:58:55 -0000	1.240
+++ rs6000-tdep.c	19 May 2005 12:57:33 -0000
@@ -2824,6 +2824,26 @@
   else
     return print_insn_little_powerpc (memaddr, info);
 }
+
+\f
+static int
+rs6000_call_insn_from_return_addr (CORE_ADDR pc, CORE_ADDR prev_pc, 
+                                   CORE_ADDR *call_pc)
+{
+  char buf[4];
+
+  if (target_read_memory (pc, buf, 4))
+    return 0;
+
+  if (extract_unsigned_integer (buf, 4) == 0x4e800020)
+    {
+      *call_pc = prev_pc - 4;
+      return 1;
+    }
+
+  return 0;
+}
+
 \f
 static CORE_ADDR
 rs6000_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
@@ -3302,6 +3322,7 @@
   set_gdbarch_convert_register_p (gdbarch, rs6000_convert_register_p);
   set_gdbarch_register_to_value (gdbarch, rs6000_register_to_value);
   set_gdbarch_value_to_register (gdbarch, rs6000_value_to_register);
+  set_gdbarch_call_insn_from_return_addr (gdbarch, rs6000_call_insn_from_return_addr);
 
   set_gdbarch_stab_reg_to_regnum (gdbarch, rs6000_stab_reg_to_regnum);
   set_gdbarch_dwarf2_reg_to_regnum (gdbarch, rs6000_dwarf2_reg_to_regnum);
Index: sparc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc-tdep.c,v
retrieving revision 1.163
diff -u -r1.163 sparc-tdep.c
--- sparc-tdep.c	14 May 2005 13:45:22 -0000	1.163
+++ sparc-tdep.c	19 May 2005 12:57:33 -0000
@@ -868,6 +868,57 @@
 }
 \f
 
+static int
+return_insn_p (unsigned int v, int *regno)
+{
+  if (v == 0x81c7e008) /* jmpl %i7+8,%g0 */
+    {
+      *regno = SPARC_I7_REGNUM;
+      return 1;
+    }
+  else if (v == 0x81c3e008) /* jmpl %o7+8,%g0 */
+    {
+      *regno = SPARC_O7_REGNUM;
+      return 1;
+    }
+  else
+    {
+      /* FIXME: more cases? */
+      return 0;
+    }
+}
+
+static int
+sparc_call_insn_from_return_addr (CORE_ADDR pc, CORE_ADDR prev_pc, 
+                                  CORE_ADDR *call_pc)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch);
+  int regno;
+
+  /* Calculating the address of the call instruction is quite tricky.
+     First we must check so that pc - 4 is a return insn, and that it
+     has already been executed (i.e., that the insn at PC is really in
+     PC-4's delay slot).  This is done by checking the value of the
+     NPC register.  */
+  
+  if (return_insn_p (sparc_fetch_instruction (pc - 4), &regno))
+    {
+      static CORE_ADDR npc, reg;
+
+      npc = sparc_address_from_register (tdep->npc_regnum);
+      reg = sparc_address_from_register (regno);
+
+      /* Set *call_pc so it points to the delay slot of the call
+         instruction.  This is needed for the "previ" case.  */
+      *call_pc = prev_pc - 4;
+      return ((reg == prev_pc - 8) && npc == prev_pc);
+    }
+
+  return 0;
+}
+
+\f
+
 /* Extract from an array REGBUF containing the (raw) register state, a
    function return value of TYPE, and copy that into VALBUF.  */
 
@@ -1211,6 +1262,8 @@
   set_gdbarch_pc_regnum (gdbarch, SPARC32_PC_REGNUM); /* %pc */
   set_gdbarch_fp0_regnum (gdbarch, SPARC_F0_REGNUM); /* %f0 */
 
+  set_gdbarch_call_insn_from_return_addr (gdbarch, sparc_call_insn_from_return_addr);
+
   /* Call dummy code.  */
   set_gdbarch_call_dummy_location (gdbarch, ON_STACK);
   set_gdbarch_push_dummy_code (gdbarch, sparc32_push_dummy_code);
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.108
diff -u -r1.108 target.c
--- target.c	16 May 2005 16:36:24 -0000	1.108
+++ target.c	19 May 2005 12:57:33 -0000
@@ -457,6 +457,7 @@
       INHERIT (to_make_corefile_notes, t);
       INHERIT (to_get_thread_local_address, t);
       INHERIT (to_magic, t);
+      INHERIT (to_reverse, t);
     }
 #undef INHERIT
 
Index: target.h
===================================================================
RCS file: /cvs/src/src/gdb/target.h,v
retrieving revision 1.73
diff -u -r1.73 target.h
--- target.h	16 May 2005 04:45:43 -0000	1.73
+++ target.h	19 May 2005 12:57:33 -0000
@@ -425,6 +425,7 @@
     int to_magic;
     /* Need sub-structure for target machine related rather than comm related?
      */
+    int (*to_reverse) (ptid_t, int);
   };
 
 /* Magic number for checking ops size.  If a struct doesn't end with this
@@ -498,6 +499,16 @@
     (*current_target.to_resume) (ptid, step, siggnal);			\
   } while (0)
 
+/* Resume execution of the process TPID, but run in reverse.  STEP
+   says whether to single-step or to run free.  Returns -1 if the
+   target does not support reverse execution.  */
+
+#define target_reverse(ptid, step)					\
+  (current_target.to_reverse 						\
+   ? (*current_target.to_reverse) (ptid, step) : -1)
+
+#define target_reserve_p() (current_target.to_reserve ? 1 : 0)
+
 /* Wait for process pid to do something.  PTID = -1 to wait for any
    pid to do something.  Return pid of child, or -1 in case of error;
    store status through argument pointer STATUS.  Note that it is

Re: [discuss] Support for reverse-execution

[Dan Shearer]

Johan Rydberg, a developer at Virtutech, has got some patches against
6.3 (for discussion only) that he'll be sending along to this list. I
want to bring up bookmarks for discussion, a topic that isn't yet
addressed by his patches.

First, what is addressed: Johan has implemented the reverse instructions
rstep, rstepi, rnext and rnexti for PowerPC, Sparc and Sparc64 targets.
Next to appear will be rcontinue (easy) and rfinish (not so easy),
however all of these are obvious reversible analogues to the
conventional commands. You should see these when Sweden wakes up next.

Bookmarks are not about reversibility, they are about checkpointing.

To understand bookmarks you first have to think about what a reversible
target is. Any simulator (or real hardware for that matter) capable of
reversibility has a mechanism to keep or re-generate all system state
and the ability to restart execution from any point in that stored
state. Bookmarking is a way of exposing this functionality to the user.

Imagine two new gdb commands, get-bookmark and goto-bookmark.
get-bookmark asks the simulator for a token which uniquely identifies
the current state of the system. goto-bookmark gives a token back to the
simulator and asks the simulator to load system state as it was at the
time of the bookmark. The token is an arbitary number that makes sense
to the particular simulator. Some might count in clock cycles, others in
milliseconds or maybe the number of the checkpoint that corresponds to
the state at that time. All gdb knows about is the value of the
bookmark.

This gives a gdb user the capability to explore alternative futures
without a complicated interface. A sequence might be get-bookmark,
change a value, run for ten seconds. Break, goto-bookmark, try another
value and run for ten seconds. Like an infinite rewind-replay facility,
very helpful when part of the pain is getting the circumstances just
right for the bug to appear.

It would be an interesting discussion to see how bookmarks could be
incorporated into the gdb framework.

-- 
Dan Shearer
dan@shearer.org

Re: [discuss] Support for reverse-execution

[Eli Zaretskii]

> From: "Michael Snyder" <msnyder@redhat.com>
> Date: Thu, 12 May 2005 16:08:34 -0700
> 
> I'd like to start adding some commands to gdb to support targets
> that can perform reverse execution (eg. stepping backwards).
> This concept has been around for a number of years now, and I
> have access to a target (the Simics simulator from Virtutech)
> that does it quite handily.

Sounds like a great idea.

> I propose we add something like the following commands
> (names open to discussion):
> 
> reverse-continue -- start executing backwards until something
> interesting happens (most likely hitting a breakpoint).
> 
> reverse-stepi -- "un-execute" the previous instruction.
> 
> reverse-step -- "un-execute" the previous source line.
> 
> reverse-finish or "un-call" -- proceed backward until 
> the current function is about to be called by its caller.
> 
> reverse-until... etc.

Not "reverse", "backwards" or "back".  "Reverse" will become ambiguous
once we have two possible directions.

> Along with these commands, we would need at least two new
> remote-protocol messages: "rc" for reverse-continue, and "rs" 
> for reverse-stepi.  I think all of the above user commands could
> be implemented on these primatives.  Obviously if the remote
> target doesn't understand these primatives, the user command 
> would error.
> 
> Finally, we'd need a new entry for the target vector --
> something like "to_resume_backwards".  If the target vector
> doesn't export this method, the user command would error.

Please don't forget the manual changes for these features.

[discuss] Support for reverse-execution

[Michael Snyder]

I'd like to start adding some commands to gdb to support targets
that can perform reverse execution (eg. stepping backwards).
This concept has been around for a number of years now, and I
have access to a target (the Simics simulator from Virtutech)
that does it quite handily.

I propose we add something like the following commands
(names open to discussion):

reverse-continue -- start executing backwards until something
interesting happens (most likely hitting a breakpoint).

reverse-stepi -- "un-execute" the previous instruction.

reverse-step -- "un-execute" the previous source line.

reverse-finish or "un-call" -- proceed backward until 
the current function is about to be called by its caller.

reverse-until... etc.

Along with these commands, we would need at least two new
remote-protocol messages: "rc" for reverse-continue, and "rs" 
for reverse-stepi.  I think all of the above user commands could
be implemented on these primatives.  Obviously if the remote
target doesn't understand these primatives, the user command 
would error.

Finally, we'd need a new entry for the target vector --
something like "to_resume_backwards".  If the target vector
doesn't export this method, the user command would error.

At least one target (the Simics simulator) would support these
commands immediately, and once they exist, their presence may
encourage other targets to implement reverse execution.  We know
that the technology exists, it just needs a user interface to be useful.

Comments?

Michael Snyder
Red Hat