Re: [discuss] Support for reverse-execution

[Dan Shearer <dan@shearer.org>]

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