From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31917 invoked by alias); 8 Sep 2005 21:41:43 -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 31775 invoked by uid 22791); 8 Sep 2005 21:41:30 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 08 Sep 2005 21:41:30 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j88LfKmu000649; Thu, 8 Sep 2005 14:41:20 -0700 (PDT) Received: from [17.219.206.114] (unknown [17.219.206.114]) by relay5.apple.com (Apple SCV relay) with ESMTP id 21500324013; Thu, 8 Sep 2005 14:41:20 -0700 (PDT) Message-ID: <4320AFFE.9080902@apple.com> Date: Thu, 08 Sep 2005 21:41:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Michael Snyder Cc: GDB Patches , jrydberg@virtutech.com Subject: Re: [RFC] reverse-step, reverse-next References: <431F6D55.5040501@redhat.com> In-Reply-To: <431F6D55.5040501@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00054.txt.bz2 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. > 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, and both it and get_exec_direction are target vector entries? BTW, I have a little discussion of usage models for reverse execution that I'm planning to post on Monday. Stan