From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30915 invoked by alias); 6 Jan 2006 19:57:34 -0000 Received: (qmail 30733 invoked by uid 22791); 6 Jan 2006 19:57:34 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 06 Jan 2006 19:57:33 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EuxiC-000518-JU; Fri, 06 Jan 2006 14:57:21 -0500 Date: Fri, 06 Jan 2006 19:57:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: gdb@sources.redhat.com, Johan Rydberg , "Frank Ch. Eigler" , Dave Brolley , Eric Bachalo Subject: Re: Return to Reverse Execution Message-ID: <20060106195720.GB18951@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb@sources.redhat.com, Johan Rydberg , "Frank Ch. Eigler" , Dave Brolley , Eric Bachalo References: <43BC376F.4000307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BC376F.4000307@redhat.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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/msg00047.txt.bz2 On Wed, Jan 04, 2006 at 01:00:31PM -0800, Michael Snyder wrote: > 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) I'm fine with these names. I think that we are not going to reach a consensus on whether "reverse" or "back" is better, but I don't think that means we should offer both; I think we should just pick one, use it consistently, and document it consistently. > 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. I guess choice is good. I'm not convinced that this is very useful, but if it's easy... we can add it and see if people use it. > 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. There's no "etc" that I can see. I would have suggested adding an argument to proceed() and letting the GDB core handle any persistent "direction" state, instead - otherwise most targets are going to have to store the exec direction in a local variable, and the core will have to keep track of what it last told the target, or call this unconditionally before every proceed. > 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... This isn't adequate unless you want to flat-out reject this for threaded situations - I think we need to at least consider what it would mean, first. Should these live in vCont? -- Daniel Jacobowitz CodeSourcery