Re: [RFA] Linux Checkpoint/Restart, take 2 (footnote)

[Michael Snyder <msnyder@redhat.com>]

Daniel Jacobowitz wrote:

> I totally don't understand what the clobber_regs bits are for. You're
> using fork as a backend; each saved fork had better have both its own
> registers, right?  Is it just a GDB internal bookkeeping thing?  If so,
> why do you need to do it for saved forks and not for the existing
> follow-fork bits?

OK, here's the thing.  If we switch contexts to a fork that was
actually created by the user process, we actually don't need the
saved copy of the regcache -- we can simply allow gdb to fetch
the regs from the "new" inferior_ptid.

But if we do that for a checkpoint fork, it's not gonna work,
because when THAT process was created, it was in a function
(fork) that was called by gdb.  So its register state and stack
are in the state as set up by Call-Function-By-Hand.  In other
words, when it was "frozen", it was before returning to CFBH,
and therefore CFBH had not yet had a chance to restore the
pre-CFBH register state.

So we have to do that now.  It's just a bit of post-cleanup
from after the CFBH state, and we don't in fact want to do it
for the "natural" forks, because if we did, we would be restoring
the register state of the parent, not the child, and that would
(usually) include the return value of fork.  Not good.

In the case of the gdb-created forks, we actually *want* to
restore the parent's register state.  Hence the difference.

Clear now?   ;-)

Michael