Folks, this isn't for commit, just for discussion.

Attached is an experimental patch that adds a command
"restore-core-file" or "rcore", which is the inverse of
"generate-core-file" (gcore).  Instead of copying the
memory and register state of a process into a file,
it takes an existing corefile, and copies its memory
and register state into the child process.

The idea was to experiment with the concept of doing
checkpoint and restore, by using a corefile as the
checkpoint file.  Obviously it has limitations --
it doesn't save any kernel state, I/O state etc.
Just user state.

But it turns out that if you avoid those limitations,
it works!  As a conservative rule of thumb, you can
go back to an earlier state so long as you don't cross
a system call.  And in practice there are lots of
system calls that can be regarded as "stateless",
or that change only user state -- so you can cross
those.

I've only tried it on Linux, but it seems to me that
it should be pretty portable, at least to hosts for
which 'gcore' works.

This may be useful for anyone who wants to experiment
with the idea of checkpoint and restart, get a feel
for how it would work in practice, and look for
"gotchas" where the sudden state change might interfere
with something else in gdb.  For a "real" checkpoint
and restart facility, we would probably want to handle
some amount of kernel state and I/O state, but
gcore/rcore might even be somewhat useful as-is
(at least to a knowledgeable user who understands
their limitations).