From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7697 invoked by alias); 7 Feb 2014 09:14:21 -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 7582 invoked by uid 89); 7 Feb 2014 09:14:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2014 09:14:19 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1WBhVn-0000Yp-Uj from Yao_Qi@mentor.com ; Fri, 07 Feb 2014 01:14:15 -0800 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Feb 2014 01:14:15 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.2.247.3; Fri, 7 Feb 2014 01:14:14 -0800 Message-ID: <52F4A366.6060704@codesourcery.com> Date: Fri, 07 Feb 2014 09:14:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: andre CC: Subject: Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands References: <1390549587-23625-1-git-send-email-yao@codesourcery.com> <52F381B0.4010602@codesourcery.com> <20140206203936.GA7055@klara.mpi.htwm.de> In-Reply-To: <20140206203936.GA7055@klara.mpi.htwm.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00189.txt.bz2 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 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. > 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. #1 is fine to me. 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. > > 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. -- Yao (齐尧)