From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4534 invoked by alias); 27 Jul 2010 17:33:22 -0000 Received: (qmail 4520 invoked by uid 22791); 27 Jul 2010 17:33:21 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Jul 2010 17:33:11 +0000 Received: (qmail 7764 invoked from network); 27 Jul 2010 17:33:10 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Jul 2010 17:33:10 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: preserving checkpoints across sessions Date: Tue, 27 Jul 2010 17:33:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; x86_64; ; ) Cc: Michael Snyder , Marc Khouzam , "'Mathew Yeates'" References: <4C4F13B3.1040909@vmware.com> In-Reply-To: <4C4F13B3.1040909@vmware.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201007271833.08136.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-07/txt/msg00102.txt.bz2 On Tuesday 27 July 2010 18:13:23, Michael Snyder wrote: > Marc Khouzam wrote: > >> -----Original Message----- > >> From: gdb-owner@sourceware.org=20 > >> [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. > >=20 > > 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. >=20 > I frankly don't see any way to implement it. > I'm open to suggestions. >=20 I don't see a way with the forks based implementation, but it may be interesting to try replacing it by a=20 backend based on something this: This might help target record too. =46rom 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. --=20 Pedro Alves