From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24264 invoked by alias); 14 Sep 2009 15:23:57 -0000 Received: (qmail 24251 invoked by uid 22791); 14 Sep 2009 15:23:56 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 15:23:48 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5E9C42BAB1F; Mon, 14 Sep 2009 11:23:46 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SAd1ohrWurH8; Mon, 14 Sep 2009 11:23:46 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 00F462BAB77; Mon, 14 Sep 2009 11:23:45 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 3185CF589B; Mon, 14 Sep 2009 08:23:41 -0700 (PDT) Date: Mon, 14 Sep 2009 15:23:00 -0000 From: Joel Brobecker To: Marc Khouzam Cc: "'gdb-patches@sourceware.org'" Subject: Re: Another proposal for frontends and queries. Message-ID: <20090914152341.GG8327@adacore.com> References: <20090914140910.GD8327@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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-09/txt/msg00403.txt.bz2 > > The only issue, really, is how to detect that situation from the FE > > so that it can itself ask the user for confirmation before it sends > > the command... > > If a FE wants to ask the user directly, it can do that no matter > what GDB will do. So I don't think there is a problem here. But > maybe I misundertood your point? Another way to look at what I was trying to say is to compare the situation between GDB/CLI and GDB/MI: 1. In the first case, if you do: (gdb) print a = 2 You should get a query from the debugger informing you that you are about to change some memory and therefore lose the record log. Are you sure? 2. In the second case, assuming that the query gets auto-answered to 'y', you will not see the query, and you will lose your record log without having a chance to abort the operation. In this regard, the CLI interface is better (IMO). Usually, I would guess that FEs do sanity checks, asking users confirmation before sending an operation that could have unwanted consequences. For instance, before sending the "quit" command, they ask the user to confirm that they want to quit. In this particular case, however, it's not clear how to perform any sanity check at the FE level. Nor does it seem desirable, as it would duplicate in the FE some of the logic we already have in GDB. There is also what you said: > Having a switch on a command turns out to be insufficient because > there is not a 1-1 mapping between queries and commands. Currently > PRecord will query before changing memory, but this will be triggered > by any of: > -var-assign a 8 > p a=8 > set var a=8 After having written all this, it seems to me that I am suggesting a level of complexity that is unnecessary, at least for now. Changing the nquery to a query seems like the right thing to do, and would render all these considerations OBE. -- Joel