From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17625 invoked by alias); 18 Dec 2008 09:16:23 -0000 Received: (qmail 17614 invoked by uid 22791); 18 Dec 2008 09:16:23 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_40 X-Spam-Check-By: sourceware.org Received: from oden.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 09:15:33 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 0204726EE73; Thu, 18 Dec 2008 10:15:31 +0100 (CET) Received: from polhem (polhem.hq.vtech [10.0.0.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id CCF2A26EE4A; Thu, 18 Dec 2008 10:15:30 +0100 (CET) From: "Jakob Engblom" To: "'Vladimir Prus'" , References: <49463870.6080302@virtutech.com> <494A0A9C.6020809@virtutech.com> In-Reply-To: Subject: RE: reverse for GDB/MI Date: Thu, 18 Dec 2008 09:16:00 -0000 Message-ID: <000a01c960f1$2c88d6c0$859a8440$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2008-12/txt/msg00321.txt.bz2 > >> 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 cert= ainly looks like the most straightforward and easy-to-understand solution.=20 > > > > 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. >=20 > 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 f= rom doing reverse execution on a large scale for the past four years.=20 First of all, the logic in the implementation side is very different for fo= rward and backward step. Second, going into that logic is simpler with a separat= e 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 a= nd either return an error or take some other action. Why complicate it like th= at? 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. 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.=20 This is also inline with the gdb command line structure, and I think it eas= es understanding the system as a whole if all command interfaces use a similar semantic structure.=20 Note that on a conceptual level there are new possibilities in reverse exec= ution 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 forw= ard, 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).=20 Best regards, /jakob _______________________________________________________ Jakob Engblom, PhD, Technical Marketing Manager Virtutech Direct: +46 8 690 07 47=20=20=20=20 Drottningholmsv=E4gen 14 Mobile: +46 709 242 646=20=20=20 11243 Stockholm Web: www.virtutech.com=20=20 Sweden ________________________________________________________ =20