From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30289 invoked by alias); 4 Jan 2006 21:01:10 -0000 Received: (qmail 30281 invoked by uid 22791); 4 Jan 2006 21:01:09 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 21:01:08 +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 k04L16Ub015425 for ; Wed, 4 Jan 2006 16:01:07 -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 k04L16104461; Wed, 4 Jan 2006 16:01:06 -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 k04L0xib003117; Wed, 4 Jan 2006 16:01:00 -0500 Message-ID: <43BC376F.4000307@redhat.com> Date: Wed, 04 Jan 2006 21:01:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: gdb@sources.redhat.com CC: Johan Rydberg , "Frank Ch. Eigler" , Dave Brolley , Eric Bachalo Subject: Return to Reverse Execution Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00013.txt.bz2 Over the past several months, there's been some great discussion of this topic, and even some trial patches sent out for comment. I'd like to start preparing a real submission for approval. I'm testing the waters now, to see how close we may be to converging on an acceptable interface spec. So here is my proposed gdb user interface. 1) A set of new commands that mimic the existing ones, to include: reverse-step (rs) reverse-next (rn) reverse-continue (rc) reverse-finish (rf) 2) A mode setting that will cause all execution commands to be performed in reverse: set exec-direction [forward backward] That gives users the choice of backing up once, or continuously. Here's my proposed target vector interface: target_ops.to_set_exec_direction (int); This keeps the target vector simple -- no need for discreet vectors for reverse-proceed, reverse-wait etc. If the target doesn't export this method, it cannot go backwards. And here's my proposed remote protocol interface: New requests: "bs" (backward step), and "bc" (backward continue). Unlike the forward versions, they will not carry an argument for a signal number to be passed to the target -- can't think how we would implement signals in reverse... Comment? Footnote: I'm making this an interface spec, specifically to avoid tying it to any model of implementation. My idea is that GDB (core) does not know *how* the target implements reverse execution -- and does not care. It could be by using checkpoints, it could be that most of the work is done on the gdb side, or that most of the work is done on the remote side. The interface makes this invisible. It may work one way for remote, a different way for a direct simulator interface, and a completely different way for native linux or hpux. The details will be hidden either in the target module or on the other side of the target interface (eg. remote protocol). Postscript: It would probably also be a good idea to make up an interface spec for checkpoints -- this proposal doesn't address that, as I argue that it's orthogonal to reverse execution (except from the implementation side).