From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19791 invoked by alias); 23 May 2005 19:15:47 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19760 invoked by uid 22791); 23 May 2005 19:15:38 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 23 May 2005 19:15:38 +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 j4NJFbqB025536 for ; Mon, 23 May 2005 15:15:37 -0400 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 j4NJFbO28100; Mon, 23 May 2005 15:15:37 -0400 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 j4NJFZa8015977; Mon, 23 May 2005 15:15:35 -0400 Message-ID: <42922BD6.4090903@redhat.com> Date: Mon, 23 May 2005 19:15:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com Subject: Re: [discuss] going back: reverse-execution vs. checkpoint/restart References: <42922617.3050805@redhat.com> <20050523190111.GA9003@nevyn.them.org> In-Reply-To: <20050523190111.GA9003@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00291.txt.bz2 Daniel Jacobowitz wrote: > On Mon, May 23, 2005 at 11:51:03AM -0700, Michael Snyder wrote: > >>And it's quite reasonable to suppose that there is an >>evolutionary path from checkpoint/restart to reverse >>execution. We've already discussed some of the ways >>in which it could go, so I think it's virtually a given >>that it is possible to get from A to B. For that matter, >>it should be also possible to get from B to A: a target >>that only supports the rs/bs primatives should be able >>to implement checkpoint/restart in terms of them. > > > Not necessarily. Once you back up and manually make a state change it > may not be possible to get back to some other state previously reached. OK -- but that just means that for any of these requests, we must take into account the possibility that the request may fail. EG. a target may support checkpoints, but a request for a specific checkpoint may fail for reasons that only the target may know (eg. you went back in time and "killed your grandfather", so the future you remember doesn't exist any more). So, we export the simplest, most general and least restrictive interface we can think of, make no assumptions about the implementation details, and always check for failure messages.