From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5797 invoked by alias); 6 Feb 2014 20:39:42 -0000 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 Received: (qmail 5717 invoked by uid 89); 6 Feb 2014 20:39:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-HELO: mailout04.t-online.de Received: from mailout04.t-online.de (HELO mailout04.t-online.de) (194.25.134.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Feb 2014 20:39:40 +0000 Received: from fwd17.aul.t-online.de (fwd17.aul.t-online.de ) by mailout04.t-online.de with smtp id 1WBVjS-0001qU-Fh; Thu, 06 Feb 2014 21:39:34 +0100 Received: from localhost (SUVyPmZDohApSvT570t87rdRSF-IUmDI0XK0hNjEuEMAe76GJKG1nytXHo46Vx-wE-@[91.65.58.210]) by fwd17.t-online.de with esmtp id 1WBVjQ-1FlXXc0; Thu, 6 Feb 2014 21:39:32 +0100 Date: Thu, 06 Feb 2014 20:39:00 -0000 From: andre To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands Message-ID: <20140206203936.GA7055@klara.mpi.htwm.de> References: <1390549587-23625-1-git-send-email-yao@codesourcery.com> <52F381B0.4010602@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52F381B0.4010602@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00135.txt.bz2 On Thu, Feb 06, 2014 at 08:36:00PM +0800, Yao Qi wrote: > On 01/24/2014 03:46 PM, Yao Qi wrote: > > As design, =breakpoint-modified isn't emitted when breakpoints are modified > > by MI commands. This patch is to add tests for this. > > > > gdb/testsuite: > > > > 2014-01-24 Yao Qi > > > > * gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Test > > that no =breakpoint-modified is emitted when breakpoints are > > modified through MI commands. > > Ping. https://sourceware.org/ml/gdb-patches/2014-01/msg00915.html I understand the patch, but I do not understand the motivation behind the design decision to not send notifications when the change is triggered by an MI command. Let's assume a frontend wants to have a functional gdb "console" embedded, and the frontend in general runs in MI mode. A trivial implementation would pass user input unfiltered to gdb. A user can choose to type 'disable 1', or, with the same effect on gdb internal state, '-break-disable 1'. In the first case, the frontend currently will get a notification, in the second case it will not. To get reliable information about the actual gdb internal state in this setup there are essentially three choices for a frontend developer: - prevent the user from entering MI commands in the console (and try to catch all possible workarounds to sneak in MI commands nevertheless), - pre-parse user input before sending it to gdb, try to recognize MI commands that are known to not produce notifications and interpret a ^done as "all fine according to whatever you currently think 'fine' means", - ignore =breakpoint-modified notification in general and try to get full information using other means. None of these options is desirable. None would be needed if gdb in MI mode would simply announce all (non-internal) breakpoint modifications with =breakpoint-modified notifications. I would pretty much prefer notifications on all breakpoint changes in MI mode, no matter whether they are initiated by an MI or a non-MI command. Andre'