From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21606 invoked by alias); 6 Nov 2012 06:05:28 -0000 Received: (qmail 21591 invoked by uid 22791); 6 Nov 2012 06:05:27 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Nov 2012 06:05:20 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1TVcHm-00072A-BN from Yao_Qi@mentor.com ; Mon, 05 Nov 2012 22:05:18 -0800 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Nov 2012 22:05:18 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.1.289.1; Mon, 5 Nov 2012 22:05:17 -0800 Message-ID: <5098A88B.5070005@codesourcery.com> Date: Tue, 06 Nov 2012 06:05:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tom Tromey CC: Subject: Re: [RFC] MI notification on register changes References: <1350977008-28632-1-git-send-email-yao@codesourcery.com> <87lielqcba.fsf@fleche.redhat.com> <509398D8.7060104@codesourcery.com> <87zk30ot22.fsf@fleche.redhat.com> <5097941F.8080604@codesourcery.com> <874nl3n74e.fsf@fleche.redhat.com> In-Reply-To: <874nl3n74e.fsf@fleche.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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: 2012-11/txt/msg00104.txt.bz2 On 11/06/2012 04:10 AM, Tom Tromey wrote: > I think the implication is that nearly any change can require the front > end to need to reset everything and so trying to make gdb differentiate > between the various events will never work out. So, gdb might as well > emit something very generic rather than =register-changed. > If GDB emits a very generic notification (for register change, memory change, etc), I am not sure how useful it is. It would be noisy to frondend, IMO. Do we have to emit this notification if the frontend requests to modify data in memory? because memory change may affect some register. > For example, a register change can affect the variable view, the memory > view (if the register is from some more-outer frame and the user is > viewing the stack), the backtrace view, etc. > > Or, a memory change can also affect any of these, including the register > view if the changed memory happens to be where a register is stored. > I agree with your points. > So, in general, it seems the only safe thing for a front end is to just > refresh everything on any change. > Not really. That is true to GDB internal states update, because GDB is not clear what is the effect of a register change or memory change. It is safe to reset everything, as you said. However, for notifications to external clients, such as MI front-end, I am not sure it is a good idea to emit such notification to MI front-end "everything will be changed" just because GDB doesn't exactly know what will happen to the inferior. My rationale here is like this: for the gdb internal state update, false positive (notify observers, but nothing is changed in fact) is fine and false negative (something is changed but observers are not notified) is not allowed. For the external notification to clients, false negative is fine (it is a limitation of gdb, and will only happen in some corner cases), but false positive is noisy. -- Yao