From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1703 invoked by alias); 7 Nov 2012 18:18:33 -0000 Received: (qmail 1691 invoked by uid 22791); 7 Nov 2012 18:18:32 -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 18:18:25 +0000 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA7INOtD021943; Wed, 7 Nov 2012 12:23:30 -0600 Received: from EUSAAHC007.ericsson.se (147.117.188.93) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 7 Nov 2012 13:18:18 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 13:18:18 -0500 From: Marc Khouzam To: "'Pedro Alves'" CC: =?iso-8859-1?Q?=27Andr=E9_P=F6nitz=27?= , "'Yao Qi'" , "'Tom Tromey'" , "'gdb-patches@sourceware.org'" Subject: RE: [RFC] MI notification on register changes Date: Wed, 07 Nov 2012 18:18: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> <509A93C0.9020009@redhat.com> In-Reply-To: <509A93C0.9020009@redhat.com> 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/msg00161.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com]=20 > Sent: Wednesday, November 07, 2012 12:01 PM > To: Marc Khouzam > Cc: 'Andr=E9 P=F6nitz'; 'Yao Qi'; 'Tom Tromey';=20 > 'gdb-patches@sourceware.org' > Subject: Re: [RFC] MI notification on register changes >=20 > Marc Khouzam wrote: >=20 > >> Andr=E9 P=F6nitz wrote: > >> On Tue, Nov 06, 2012 at 02:04:59PM +0800, Yao Qi wrote: > >>> 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. > >> > >> Why? > >> > >> As soon as a single bit changes somewhere, the only=20 > formally correct > >> response from a frontend is to re-fetch everything. > >=20 > > IIUC, the notifications being proposed will only be triggered if > > registers are changed by the user. This is something that=20 > the frontend > > needs to be told about because the assumption is that=20 > 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. >=20 > The issue is in the "contain the changed info" part. In=20 > general, we don't have such > info available. So there are cases where trusting such fine-grained > notifications will get you stale views. For example, in the=20 > general case, if the > user changes registers/memory, we can't assume that=20 > memory/registers didn't change. > Some targets even have memory-mapped registers. If GDB core=20 > shouldn't assume such > things, then "registers changed" or "memory changed"=20 > notifications are in general > misleading. We'd have to add notes like "note that even=20 > though we're saying only > a register changed, everything else (memory, stack frame,=20 > whole stack, etc.) > might have changed too, so you're better off refreshing all=20 > your views." which may > be a bit silly. We may be better off not giving ourselves=20 > and the frontends rope to hang ourselves with. Ok, I understand the problem now. It should probably up to GDB to determine, if possible, the safe cases which can specify the "changed info" and=20 the unsafe cases which should not, therefore telling the=20 frontend to do a full refresh. Which brings your next question: > The related question is then, why is a full refresh an issue,=20 > if that is something > the must already do after every stop, such as e.g., after=20 > each "step". As PR 7574 > hints at, things like "step" are the use cases users will=20 > notice and complain > the most if slow. It seems like optimizing the frontends=20 > with selecting/partial updates > for some cases still leaves you with needing to optimize the=20 > full-refresh case > anyway for more important cases. Avoiding a full refresh is probably a result of inertia. Since GDB allows the frontend to try to avoid a full refresh by giving extra information in its notifications, the idea of continuing with that approach seemed the right one. For instance, GDB could have a single =3Dbreakpoints-changed notif which would trigger a full refresh a breakpoints. Same for variable objects (see -var-update). Even =3Dthreads-changed (although this may be a little more justified if we think about it more deeply). Fundamentally, erroneous data is the worse case. So, having a notification without "changed data" is better=20 than an invalid or incomplete "changed data", or no notification at all :). So, if there are cases where a full refresh is needed then I can understand that it may not be worth trying to provide the "changed data" only once in a while. Thanks for the explanation. Marc