This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC] a prototype checkpoint-restart using core files
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.