Re: [RFC] a prototype checkpoint-restart using core files

[Michael Snyder <michsnyd@cisco.com>]

Daniel Jacobowitz wrote:
> On Mon, Nov 07, 2005 at 09:21:36PM +0100, Mark Kettenis wrote:
> 
>>>Date: Mon, 7 Nov 2005 14:07:24 -0500
>>>From: Daniel Jacobowitz <drow@false.org>
>>>
>>>>If I read the code correctly, there is one rather serious limitation
>>>>though: restoring mmapped area's will fail if the same area isn't
>>>>mapped in the target process.  Especially on systems that randomize
>>>>the location of mmapped memory this will make the usefullness of this
>>>>feature pretty limited :(.
>>>
>>>Why should it?  The expected use is to restore these dumps into the
>>>same running session - just after stepping a bit.  So unless you step
>>>across a very large free(), it should be fine.
>>
>>Ah, somehow I forgar about the "same running session" part.  Guess
>>that's one of the things that needs to be clearly documented then ;-).
> 
> 
> Yeah - a general purpose "restore core file" command would be neat, but
> I think, not practical enough to be useful.

Going forward in time is actually possible -- sometimes.
I can debug for a while, then save a corefile, then quit,
start a new debug session, open the same program, run to
main -- and then load the old corefile.

This bit isn't in my posted patch, but if the sbrk boundary
has been advanced, I can detect it, and do a target function
call to sbrk to bring it up to match.

Where I run into a problem is with shared libraries.
Sometimes, as Mark says, a segment hasn't been mmapped
in yet.  I don't yet know what to do about that.