From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5656 invoked by alias); 19 Dec 2008 13:32:16 -0000 Received: (qmail 5646 invoked by uid 22791); 19 Dec 2008 13:32:15 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 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; Fri, 19 Dec 2008 13:31:35 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 0024526F689; Fri, 19 Dec 2008 14:31:29 +0100 (CET) Received: from polhem (c83-253-21-188.bredband.comhem.se [83.253.21.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 56A8026F674; Fri, 19 Dec 2008 14:31:29 +0100 (CET) From: "Jakob Engblom" To: "'Pedro Alves'" , Cc: "'Joel Brobecker'" , "Tomas Holmberg" , "'Vladimir Prus'" References: <49463870.6080302@virtutech.com> <494B5A82.4020004@virtutech.com> <20081219110636.GA3793@adacore.com> <200812191322.09555.pedro@codesourcery.com> In-Reply-To: <200812191322.09555.pedro@codesourcery.com> Subject: RE: reverse for GDB/MI Date: Fri, 19 Dec 2008 13:32:00 -0000 Message-ID: <002b01c961de$197b1320$4c713960$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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/msg00344.txt.bz2 > Me too. It's confusing because "reverse-finish" isn't really doing a reverse > "finish". If it were, a "finish", followed by a "reverse-finish" (or the > other way around) would bring you to the original state, like a "step" followed > by > a "reverse-step" tries to (it can't be 100% accurate, but still). Good point. Reverse-x naming works when x and rev-x cancel each other. Which is pretty much limited to instruction step or moving a certain number of machine instructions forward or backward. On source level, you get other expected behavior. For example, if you have A; Call(b); C; And sit at "C" and do a reverse-step, you might well end up at A as that is stepping back in the same function. While inside b, doing a step that hits a return will put you at C, but unstepping is then contrained to do so in the scope you are in. Anything else than instruction back or forward can have asymmetric behavior due to the way function scope affect the behavior of debugging commands. > I think someone just proposed to rename "reverse-finish" to "uncall", that > although > may sound weird at first, states much clearly what the "reverse-finish" command > really does. Uncall is a good name, as it makes it much clearer what is going on. /jakob