Hi folk,

The attached patch, again, is for discussion and review, not
for approval or commit.  This patch adds a first-cut implementation
of checkpoint and restart commands, based on fork instead of
on corefiles.

Sorry, but it will only work on Linux.  Or possibly HPUX.
It requires the same functionality as follow-fork.

In this prototype version, I just copied code from various
places (notably thread.c) into linux-nat.  There are four
new commands:
  * checkpoint
  * restart <n>
  * info checkpoint
  * delete-checkpoint <n>

When you ask for a checkpoint, gdb causes the inferior to fork.
It captures the new child with ptrace, and just sets it aside
while you continue to debug the original process.

When you want to restart from an earlier checkpoint, gdb just
switches to the child process that it saved earlier, and lets
you debug that process.

The advantages over the corefile method are:
   * fork captures kernel state as well as user state
   * fork is cheaper (faster) than saving a corefile, esp.
     on linux (where thanks to copy-on-write, it's virtually
     free).

This patch basically works, but is not complete.  I've
used it to debug gdb, keeping as many as 14 active
"checkpoint" forks, and switching around between them.
14 being an arbitrary stopping point, not a limit.   ;-)

I can go all the way back from the gdb prompt (after
loading symbols) to the first statement in main, and
back again (or to any point in between), repeatedly.
I can step, next, continue, and hit breakpoints in any
of the child processes, and even do target function calls.

Since this is a step into new territory (gdb is actually
debugging multiple processes), there are a number of
things I haven't addressed yet, such as what to do if
one of the processes exits.  There's no theoretical
reason why we can't continue to debug the others, but
"mourn_inferior" isn't currently set up for that.

I also have a "ghost bug" or two -- several times I've
had one of the child processes either crash or hang in
malloc, and I don't know why.  Hopefully it's soluble.

Daniel -- this functionality should be easily adaptable
to the follow-fork task -- we should be able to set a mode
bit so that instead of detaching from the (child or parent),
gdb simply suspends one of them and debugs the other, allowing
the user to switch back and forth between them.  I haven't
tried to implement it yet, but it should be straightforward.

I'd be thrilled if folks would try it out and comment.

Michael