From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29896 invoked by alias); 5 Feb 2009 09:38:59 -0000 Received: (qmail 29888 invoked by uid 22791); 5 Feb 2009 09:38:59 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Feb 2009 09:38:51 +0000 Received: (qmail 1266 invoked from network); 5 Feb 2009 09:38:49 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Feb 2009 09:38:49 -0000 From: Vladimir Prus To: "Jakob Engblom" , Tomas Holmberg Subject: Re: reverse for GDB/MI Date: Thu, 05 Feb 2009 09:38:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sources.redhat.com References: <49463870.6080302@virtutech.com> <000a01c960f1$2c88d6c0$859a8440$@com> In-Reply-To: <000a01c960f1$2c88d6c0$859a8440$@com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200902051239.27523.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00117.txt.bz2 On Thursday 18 December 2008 12:15:29 Jakob Engblom wrote: > > >> I am not quite sure about adding new set of commands for that. Can we use > > >> --reverse option, thereby not introducing new commands? > > What would be the gain from NOT adding the commands, as you see it? It certainly > looks like the most straightforward and easy-to-understand solution. > > > > > > > Adding a reverse option to the existing commands is possible. But I do > > > not think it is a good idea. It is not always obvious what should > > > happen when running a standard command in reverse. > > > > Why? -exec-step always steps forward. -exec-step --reverse always steps > > backward. Seems like a fairly simple model to me. > > Overall, it is not that simple, unfortunately, and that is our experience from > doing reverse execution on a large scale for the past four years. > > First of all, the logic in the implementation side is very different for forward > and backward step. Second, going into that logic is simpler with a separate set > of commands -- much easier both to send out and parse in the code, as the > reverse bits are obviously separated. Having a --reverse flag will force > command handlers that only deal with the normal case to check for reverse and > either return an error or take some other action. Why complicate it like that? I assume that the 'set exec-direction' command happens to already work in FSF GDB? Then, I'd claim that --reverse is actually trivial. > If you cannot do reverse, having a set of reverse commands that is clearly > defined by looking just at the command makes ignoring them easier. Ignoring where, by whom, and for what purpose? > There is no > shortage of name space in MI, and thus I cannot see that there is any value to > making things more complicated with an extra flag. It seems to be that it's best to have some structure in MI commands and flags. Say, we have continue and reverse-continue. What if you want some other form of continue, say "continue for N seconds". Should we have then: continue reverse-continue timed-continue reverse-timed-continue ? That would be fairly cumbersome. Also, the --reverse option can be documented with a single paragraph, whilst individual commands should all have individual documentation. > This is also inline with the gdb command line structure, and I think it eases > understanding the system as a whole if all command interfaces use a similar > semantic structure. > > Note that on a conceptual level there are new possibilities in reverse execution > that do not exist in classic unidirectional debugging. For example, "go to time > point P". Since a classic unidirectional debugger can only stop or go forward, > this concept did not exist in such a form. This is not part of the current > patch, but certainly can be seen to come up moving forward (or it might be > already part of bookmarking in the reverse gdb). To summarize, I would like the patch to be adjusted in the following way: 1. Use --reverse option 2. Arrange for --exec-step, and similar, to ignore 'set exec-direction', since all new MI commands should strive to be stateless. This, of course, will mean that one cannot get existing frontend to do reverse step by typing a command into CLI console, but it is not obvious if existing frontend will work without modification anyway. 3. Include documentation 4. Include testcases Thanks, Volodya