From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26240 invoked by alias); 23 May 2005 18:51:14 -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 26161 invoked by uid 22791); 23 May 2005 18:51:07 -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 18:51:07 +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 j4NIp5Cr017102 for ; Mon, 23 May 2005 14:51:05 -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 j4NIp5O20027 for ; Mon, 23 May 2005 14:51:05 -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 j4NIp3a8014368 for ; Mon, 23 May 2005 14:51:04 -0400 Message-ID: <42922617.3050805@redhat.com> Date: Mon, 23 May 2005 18:51:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: [discuss] going back: reverse-execution vs. checkpoint/restart Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00289.txt.bz2 Last week I was beginning to lean in the direction of Paul's and Frank's viewpoint. On reflection, I think I can argue that the two are not mutually exclusive. As Frank points out, the "rs/bs" and "rc/bc" primatives are useful only for a really clever target -- one that not only has a means of backing up to a previous state, but can do it at single-instruction granularity, fast and efficiently, and has worked out a lot of the 'kinks' that a lot of us haven't even thought about yet. And as Paul points out, there is currently only one such target that we know of. The bookmark (or checkpoint/restart) model is a considerably smaller and less daunting "chunk" for the target-side implementer to take on at one go -- and is not necessarily limited to simulators. If gdb implemented an interface for checkpoint/restart, there's a good chance that a number of targets would soon take advantage of it. 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. How much of that evolution needs to take place on the gdb side, and how much on the target side, is a great field for discussion -- I would only note that we do not have to answer that question now. If we convince ourselves that both sets of primatives are useful for some targets, and that one may evolve into the other, then there is no reason not to implement them both. Being able to do either one but not the other would be better than not being able to do either. Certainly users have been asking for checkpoint/restart for years, if not decades. It would be very cool if we could give it to them, with an interface that lends itself to porting to various target environments. And certainly the idea of reverse execution has been around for years too, and it would be cool to be able to support that. So why settle for one or the other? The beauty of gdb is that it doesn't need to know HOW the target accomplishes a thing. Details such as whether the cached states are kept in a circular buffer are for the target implementers to worry about. We just define our interface specification to be as general as possible. The less we assume about the target-side implementation, the better. That said -- it's still useful and fun to discuss how these things may be accomplished, and should help us to design a generally useful interface.