From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-23091-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10433 invoked by alias); 7 Nov 2005 20:22:23 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 10420 invoked by uid 22791); 7 Nov 2005 20:22:20 -0000
Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 07 Nov 2005 20:22:20 +0000
Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2])
	by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id jA7KLa02019350;
	Mon, 7 Nov 2005 21:21:37 +0100 (CET)
Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1])
	by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id jA7KLaW7032754;
	Mon, 7 Nov 2005 21:21:36 +0100 (CET)
Received: (from kettenis@localhost)
	by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jA7KLanV015248;
	Mon, 7 Nov 2005 21:21:36 +0100 (CET)
Date: Mon, 07 Nov 2005 20:22:00 -0000
Message-Id: <200511072021.jA7KLanV015248@elgar.sibelius.xs4all.nl>
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
CC: michsnyd@cisco.com, gdb@sources.redhat.com, eliz@gnu.org
In-reply-to: <20051107190724.GA19531@nevyn.them.org> (message from Daniel
	Jacobowitz on Mon, 7 Nov 2005 14:07:24 -0500)
Subject: Re: [RFC] a prototype checkpoint-restart using core files
References: <43696953.9090601@cisco.com> <20051107001937.GG19200@nevyn.them.org> <u64r5f4uh.fsf@gnu.org> <200511071857.jA7IvP4K005599@elgar.sibelius.xs4all.nl> <20051107190724.GA19531@nevyn.them.org>
X-SW-Source: 2005-11/txt/msg00161.txt.bz2

> Date: Mon, 7 Nov 2005 14:07:24 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> > 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 ;-).

Thanks Daniel,

Mark