This is the mail archive of the
mailing list for the GDB project.
Re: preserving checkpoints across sessions
On Tuesday 27 July 2010 18:13:23, Michael Snyder wrote:
> Marc Khouzam wrote:
> >> -----Original Message-----
> >> From: firstname.lastname@example.org
> >> [mailto:email@example.com] On Behalf Of Mathew Yeates
> >> Sent: Thursday, July 22, 2010 10:06 PM
> >> To: firstname.lastname@example.org
> >> Subject: preserving checkpoints across sessions
> >> I looked at the checkpoint code and I "sort of" see how it could be
> >> done but I'm no gdb guru.
> >> Somebody add this! It would be a great feature. You could add
> >> checkpoints throughout your executable and be able to start a gdb
> >> session and go directly to a desired location.
> > I also think this would be a nice feature.
> > In fact, I thought that is how checkpoints worked already :-O
> > I was planning on adding this support in Eclipse. I guess
> > I'll have to wait for it to be supported in GDB first.
> I frankly don't see any way to implement it.
> I'm open to suggestions.
I don't see a way with the forks based implementation, but
it may be interesting to try replacing it by a
backend based on something this:
This might help target record too.
From the FAQ, linked above:
How is checkpoint/restart different than SIGSTOP/SIGCONT?
Putting a process to sleep (via the SIGSTOP signal) implies
stopping its execution. Taking a checkpoint writes a snapshot
of a process to disk: the process may either be allowed to
continue running after the checkpoint is complete, or you can
kill the process to release all of its resources .
With sleep, a process's resources are not all fully
released (such as virtual memory, network connections,
process id, etc.). Checkpointing then killing a process fully
releases all system resources.
Restarts from checkpoint files can be used across machine
reboots, and/or even on different machines than the one that
the checkpoint was taken on. This is not true for SIGCONT.
How is BLCR different than "user-level" checkpointing libraries
like Condor, etc.?
BLCR performs checkpointing and restarting inside the linux
kernel. While this makes it less portable than solutions that
use user-level libraries, it also means that it has full
access to all kernel resources, and can thus restore
resources (like process IDs) that user-level libraries
cannot. This also allows BLCR to checkpoint/restart groups of
processes (such as shell scripts and their subprocesses),
together with the pipes that connect them.