From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23580 invoked by alias); 18 Nov 2005 03:37:03 -0000 Received: (qmail 23544 invoked by uid 22791); 18 Nov 2005 03:37:00 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 03:37:00 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jAI3awF9029911; Thu, 17 Nov 2005 22:36:58 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jAI3avV21358; Thu, 17 Nov 2005 22:36:57 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id jAI3auPe031955; Thu, 17 Nov 2005 22:36:56 -0500 Message-ID: <437D4C57.10906@redhat.com> Date: Fri, 18 Nov 2005 08:18:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Stan Shebs CC: GDB Patches , gdb@sources.redhat.com Subject: Re: [RFC] a prototype checkpoint-restart using core files Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2005-11/txt/msg00309.txt.bz2 Stan Shebs wrote: > Michael Snyder wrote: >> Folks, this isn't for commit, just for discussion. >> >> Attached is an experimental patch that adds a command >> "restore-core-file" or "rcore", which is the inverse of >> "generate-core-file" (gcore). Instead of copying the >> memory and register state of a process into a file, >> it takes an existing corefile, and copies its memory >> and register state into the child process. > > My prototype is even lamer :-) I use target read/write > operations to collect state - but it can step backwards. Don't beat up on yourself -- gcore works by using target read and write. It's just a convenient file format for saving target state. > An improved version in the works uses vfork() to make > core images more cheaply. Aha! Linux fork is similar to vfork, in that it does not immediately make a copy of user memory. Did you have a chance to look at my later patch based on fork? > One idea I've considered is getting the OS to set up > some kind of notification at system calls, and then use > it to warn the user who tries to resume the inferior > after rolling back. Yeah, ptrace on linux provides such a notification. I know you don't have ptrace on your OS, but you might think about mimicing the ptrace user interface, if only so that you don't have to design one of your own. ;-) Stan, do you remember the trace/replay utility that Michael Chastain invented? I was thinking that would come in pretty handy in this context. Michael