From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13451 invoked by alias); 14 Sep 2009 14:28:27 -0000 Received: (qmail 13442 invoked by uid 22791); 14 Sep 2009 14:28:26 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 14:28:22 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n8EERra3029008; Mon, 14 Sep 2009 09:27:57 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 09:27:11 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Sep 2009 09:27:11 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 14 Sep 2009 10:27:10 -0400 From: Marc Khouzam To: "'Joel Brobecker'" CC: "'gdb-patches@sourceware.org'" Date: Mon, 14 Sep 2009 14:28:00 -0000 Subject: RE: Another proposal for frontends and queries. Message-ID: References: <20090914140910.GD8327@adacore.com> In-Reply-To: <20090914140910.GD8327@adacore.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2009-09/txt/msg00399.txt.bz2 =20 > -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com]=20 > Sent: Monday, September 14, 2009 10:09 AM > To: Marc Khouzam > Cc: gdb-patches@sourceware.org > Subject: Re: Another proposal for frontends and queries. >=20 > > Another proposal that was thrown out there was to disable queries > > when having started GDB with the MI interpreter. The idea is that > > it would be frontends that would start GDB like that, and frontends > > know what they are doing and don't need queries. > > http://sourceware.org/ml/gdb/2009-07/msg00113.html > > This seems too drastic to me. >=20 > Isn't this is the approach that has always been taken in the past? > I think that we should bite the bullet and implement this approach. As long as some solution is chosen, I'll be happy :-) > 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...=20 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? > Or perhaps, another approach is to return an error > (like it probably does now) that the frontend detect, and then provide > a switch for that command to force the execution of that=20 > command despite > the reported consequences. 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=3D8 set var a=3D8 and others. Marc