preserving checkpoints across sessions

[Pedro Alves]

On Tuesday 27 July 2010 18:13:23, Michael Snyder wrote:
> Marc Khouzam wrote:
> >> -----Original Message-----
> >> From: gdb-owner@sourceware.org 
> >> [mailto:gdb-owner@sourceware.org] On Behalf Of Mathew Yeates
> >> Sent: Thursday, July 22, 2010 10:06 PM
> >> To: gdb@sourceware.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:

<https://ftg.lbl.gov/CheckpointRestart/CheckpointRestart.shtml>

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.

-- 
Pedro Alves