From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27953 invoked by alias); 7 Nov 2005 23:56:17 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 27939 invoked by uid 22791); 7 Nov 2005 23:56:14 -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 23:56:14 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 15:56:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA7NtnO3014772; Mon, 7 Nov 2005 15:56:10 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 15:56:09 -0800 Received: from [128.107.165.67] ([128.107.165.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 15:56:09 -0800 Message-ID: <436FE999.1000801@cisco.com> Date: Mon, 07 Nov 2005 23:56: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: Daniel Jacobowitz CC: gdb@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> <20051107190724.GA19531@nevyn.them.org> <200511072021.jA7KLanV015248@elgar.sibelius.xs4all.nl> <20051107202554.GA24572@nevyn.them.org> In-Reply-To: <20051107202554.GA24572@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-11/txt/msg00184.txt.bz2 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 >>> >>>>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.