From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9102 invoked by alias); 9 Sep 2005 22:39:50 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9086 invoked by uid 22791); 9 Sep 2005 22:39:45 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 09 Sep 2005 22:39:45 +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 j89MdhxQ029350 for ; Fri, 9 Sep 2005 18:39:43 -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 j89MdgV03837; Fri, 9 Sep 2005 18:39:42 -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 j89MdaGE031534; Fri, 9 Sep 2005 18:39:37 -0400 Message-ID: <43220F28.70801@redhat.com> Date: Fri, 09 Sep 2005 22:39:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Stan Shebs CC: GDB Patches , jrydberg@virtutech.com Subject: Re: [RFC] reverse-step, reverse-next References: <431F6D55.5040501@redhat.com> <4320AFFE.9080902@apple.com> In-Reply-To: <4320AFFE.9080902@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00060.txt.bz2 Stan Shebs wrote: > Michael Snyder wrote: > >> This isn't for submission, just for discussion. This is something >> that Johan Rydberg (of Virtutech) and I have been working on. >> >> I'd like to hear what everybody thinks about this >> bit of infrun implementation for the reverse debugging >> that we discussed a few months ago. >> > Seems plausible to me. I've actually been experimenting with > a reverse execution prototype based on GDB managing all the > checkpoints, rather than pushing them down into the target as > Simics apparently does, and while GDB-managed checkpoints are > more powerful in some ways (random access to arbitrary states, > general undo), it's also looking rather more complicated. Yeah, I consider this sort of abstract and modular. My patch here makes no assumptions about how a backend does reverse execution. The backend could, for instance, call into a separate module such as yours that manages checkpoints. Another backend might do it by direct request to the target -- a la Simics. >> This part is enough to get step and next to work in reverse, >> based solely on the assumption that the backend (or someone) >> provides an interface "get_exec_direction ()", which returns >> forward or reverse. It's also assumed that the backend will >> know which direction to go (leaving user-interface issues >> out of the picture). One can imagine either a "set direction" >> interface, or a "reverse-step/reverse-continue". > > > Presumably there is a set_exec_direction, Presumably. ;-) > and both it and > get_exec_direction are target vector entries? For instance. But again, this infrun code makes no assumptions. So that decision is orthogonal -- an implementation detail. This code would be equally useful whether (a) the direction was set by a modal "set direction" command, or (b) the direction was set by a "reverse-step" command. > BTW, I have a little discussion of usage models for reverse > execution that I'm planning to post on Monday. Looking forward to it. I, in turn, have a patch to implement "reverse-finish", which I thought I'd post a little while after this one.