From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7863 invoked by alias); 7 Feb 2014 16:12:28 -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 7849 invoked by uid 89); 7 Feb 2014 16:12:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-HELO: mailout11.t-online.de Received: from mailout11.t-online.de (HELO mailout11.t-online.de) (194.25.134.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2014 16:12:26 +0000 Received: from fwd19.aul.t-online.de (fwd19.aul.t-online.de ) by mailout11.t-online.de with smtp id 1WBo2N-0007KF-Dq; Fri, 07 Feb 2014 17:12:19 +0100 Received: from localhost (EYyIbUZVYhGABx6XOWY2XZkvYQxM2OIYIMRFkHAuwDu387C3wOtFnNofKBcYwM7ZHu@[93.220.141.227]) by fwd19.t-online.de with esmtp id 1WBo2J-0m39rU0; Fri, 7 Feb 2014 17:12:15 +0100 Date: Fri, 07 Feb 2014 16:12: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: <20140207161221.GA5150@klara.mpi.htwm.de> References: <1390549587-23625-1-git-send-email-yao@codesourcery.com> <52F381B0.4010602@codesourcery.com> <20140206203936.GA7055@klara.mpi.htwm.de> <52F4A366.6060704@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52F4A366.6060704@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00211.txt.bz2 On Fri, Feb 07, 2014 at 05:12:06PM +0800, Yao Qi wrote: > On 02/07/2014 04:39 AM, andre wrote: > > 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. > > > > The rationale is mentioned here > https://sourceware.org/ml/gdb-patches/2012-07/msg00487.html Sure, but I don't understand it. You argue that it is necessary for a frontend to keep track of changes triggered by manual user interaction. That's fine. But it is unclear why this reasoning should only be applied to non-MI commands, and not for MI commands that a user enters manually (and that gdb happily accepts). > In short, we want MI frontend is aware of GDB's state changes, such as > breakpoint changes. If requested changes are from MI, MI frontend > should be aware of them, so no notifications are sent. > > 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. > > #1 is fine to me. But not for me. I don't want to needlessly restrict what my users are allowed to type, or not. It might even e.g. be useful to copy/paste/modify previously sent MI commands and send them manually via the console. In your approach this would not be possible, or at least require the user to re-write the full command in non-MI syntax. > It shouldn't be hard to do that. On the other hand, > I don't understand users have to input MI commands in console, which > is provided to accept CLI commands. The point is not that they should _have to_ use MI syntax, but that they _could_ if they wish. > > 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. > > That would be too noisy in some cases. It's easier for a frontend to filter out messages (especially if they are expected) than to act on messages that are not send. And it's not that we are talking about millions of notifications here that might the communication line.` Andre'