From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 771 invoked by alias); 8 Feb 2014 14:11:30 -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 762 invoked by uid 89); 8 Feb 2014 14:11:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-HELO: mailout03.t-online.de Received: from mailout03.t-online.de (HELO mailout03.t-online.de) (194.25.134.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Feb 2014 14:11:24 +0000 Received: from fwd07.aul.t-online.de (fwd07.aul.t-online.de ) by mailout03.t-online.de with smtp id 1WC8cm-000648-Kg; Sat, 08 Feb 2014 15:11:16 +0100 Received: from localhost (XR-Ii2Zd8hn7xZydWa+4wUCXlGFToKOM2E0dwbA+2B3vut1uAO31jIdv9Qv11UgQx8@[93.220.166.120]) by fwd07.t-online.de with esmtp id 1WC8cn-0O3VGy0; Sat, 8 Feb 2014 15:11:17 +0100 Date: Sat, 08 Feb 2014 14:11:00 -0000 From: andre To: Joel Brobecker Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands Message-ID: <20140208141122.GA15673@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> <20140207161221.GA5150@klara.mpi.htwm.de> <20140208031854.GM5485@adacore.com> <52F5A67A.7010301@codesourcery.com> <20140208131533.GN5485@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140208131533.GN5485@adacore.com> X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00247.txt.bz2 On Sat, Feb 08, 2014 at 05:15:33PM +0400, Joel Brobecker wrote: > > > One other possible option: Add a new option that would be available > > > to all commands to disable notifications related to the command being > > > executed. That way, FE could use it to reduce unnecessary back-chatter. > > > > That is what I am thinking about. I don't think the amout of information discussed here is worth any special action on neither gdb's nor a frontend's side. Normal operation produce "chatter" e.g. for library load/unload notifications on a much bigger scale. > > > I don't really like that option, though, as it would require a > > > certain transition period. > > > > What do you mean by "transition period"? We can make use of > > "-list-features" to tell FE that FE can disable/enable MI notifications > > through a certain command. > > The issue is people using older versions of an FE with a newer version of > GDB. For those, their FE wouldn't know about the new option and thus get > the notifications that they might not expect. This happened regularly with other new notifications in the past so I would expect frontends to be able to handle new notifications gracefully. In this case "new" is even relative as the notifications are sent in most circumstances already anyway. > I don't know if we need to be concerned about this sort of compatibility > or not... Since it is not a concern when introducing new notifications like =cmd-param-changed, =memory-changed or even =breakpoint-modified itself and frontends need to handle the case of "unexpected" notifications anyway, it's hard for me to see how sending a specific notification in all cases instead of in "most" cases can do harm. Andre'