From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6117 invoked by alias); 7 Nov 2005 19:43:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6054 invoked by uid 22791); 7 Nov 2005 19:43:02 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 07 Nov 2005 19:43:02 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 11:42:57 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA7JgsnT027247; Mon, 7 Nov 2005 11:42:54 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:42:51 -0800 Received: from [128.107.165.67] ([128.107.165.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:42:51 -0800 Message-ID: <436FAE3B.60209@cisco.com> Date: Mon, 07 Nov 2005 20:43:00 -0000 From: Michael Snyder User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 MIME-Version: 1.0 To: Mark Kettenis CC: gdb@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] a prototype checkpoint-restart using core files References: <43696953.9090601@cisco.com> <20051107001937.GG19200@nevyn.them.org> <200511071857.jA7IvP4K005599@elgar.sibelius.xs4all.nl> In-Reply-To: <200511071857.jA7IvP4K005599@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-11/txt/msg00085.txt.bz2 Mark Kettenis wrote: >>Date: Mon, 07 Nov 2005 06:40:22 +0200 >>From: Eli Zaretskii >> >>>Date: Sun, 6 Nov 2005 19:19:37 -0500 >>>From: Daniel Jacobowitz >>>Cc: gdb@sources.redhat.com, gdb-patches@sources.redhat.com >>> >>>I've got to say that this is amazingly cool. >>> >>>Afraid that's all the comments I have time for at the moment :-) >> >>I agree, and I'd add that getting this into GDB soon would be good. > > > Heh, I'd expected Eli to ask for documentation ;-) > > Anyway, in this cause I think that's important since I expect a lot of > users won't understand its limitations. > > 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 :(. Yes, I'm still puzzling over that one. However, it would mostly only happen (sic) if you are going forward in time, not backward. In particular, if you create a new process, then try to feed it a corefile from an old process that was further along in its execution. If you save a gcore file, run forward, and then reload the previously saved gcore file back into the *same* process (ie. go backward in time), the mmaped areas will almost always be present -- unles someone explicitly unmaps them. As for your broader point, I agree, I don't think this is ready for exposure to average users. I would like to see it get some play from "sophisticated" users such as you guys, who may understand the limitations and help to characterize them.