From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23889 invoked by alias); 7 Nov 2012 15:35:39 -0000 Received: (qmail 23784 invoked by uid 22791); 7 Nov 2012 15:35:37 -0000 X-SWARE-Spam-Status: No, hits=-4.1 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 imr4.ericy.com (HELO imr4.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Nov 2012 15:35:33 +0000 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA7FeUjr013130; Wed, 7 Nov 2012 09:40:34 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 7 Nov 2012 10:35:23 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 10:35:23 -0500 From: Marc Khouzam To: =?iso-8859-1?Q?=27Andr=E9_P=F6nitz=27?= , "'Yao Qi'" CC: "'Tom Tromey'" , "'gdb-patches@sourceware.org'" Subject: RE: [RFC] MI notification on register changes Date: Wed, 07 Nov 2012 15:35:00 -0000 Message-ID: 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> <5098A88B.5070005@codesourcery.com> <20121106200012.GA2591@klara.mpi.htwm.de> In-Reply-To: <20121106200012.GA2591@klara.mpi.htwm.de> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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/msg00147.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Andr=E9 P=F6nitz > Sent: Tuesday, November 06, 2012 3:00 PM > To: Yao Qi > Cc: Tom Tromey; gdb-patches@sourceware.org > Subject: Re: [RFC] MI notification on register changes >=20 > On Tue, Nov 06, 2012 at 02:04:59PM +0800, Yao Qi wrote: > > On 11/06/2012 04:10 AM, Tom Tromey wrote: > > >I think the implication is that nearly any change can=20 > require the front > > >end to need to reset everything and so trying to make gdb=20 > differentiate > > >between the various events will never work out. So, gdb=20 > might as well > > >emit something very generic rather than =3Dregister-changed. > > > > >=20 > > 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. >=20 > Why? >=20 > As soon as a single bit changes somewhere, the only formally correct > response from a frontend is to re-fetch everything. IIUC, the notifications being proposed will only be triggered if registers are changed by the user. This is something that the frontend needs to be told about because the assumption is that registers/memory are stable when the program is suspended. I don't believe a full refresh is needed if such notifications contain the changed info. Register changes caused by program execution are not targetted by this notification, or at least I don't think they should be. Marc > One can collect several such notification before triggering a full > refetch (no user will insist on updates everyt 50ms, and gdb won't > deliver that anyway), or one can take some risk and not refetch > everything, which in most cases would even be "good enough", but > in general a refetch is needed.=20 >=20 > [...] > > 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. >=20 > I wouldn't call "false external positives" noisy, unless they generate > so much traffic that there is a performance bottleneck. A frontend > can consciously decide to ignore them. >=20 > Andre' >=20