From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12644 invoked by alias); 6 Nov 2012 20:00:23 -0000 Received: (qmail 12633 invoked by uid 22791); 6 Nov 2012 20:00:22 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cora.hrz.tu-chemnitz.de (HELO cora.hrz.tu-chemnitz.de) (134.109.228.40) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Nov 2012 20:00:16 +0000 Received: from 91-65-59-102-dynip.superkabel.de ([91.65.59.102] helo=localhost) by cora.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1TVpJl-00042Y-Pm; Tue, 06 Nov 2012 21:00:14 +0100 Date: Tue, 06 Nov 2012 20:00:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Yao Qi Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC] MI notification on register changes Message-ID: <20121106200012.GA2591@klara.mpi.htwm.de> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5098A88B.5070005@codesourcery.com> X-purgate: clean.bounce X-purgate-type: clean.bounce X-purgate-ID: 154106::1352232014-00000CD1-A803EF9D/0-0/0-18 X-Scan-AV: cora.hrz.tu-chemnitz.de;2012-11-06 21:00:13;dfa90b570d9339976dbec52f6fcc66d0 X-Scan-SA: cora.hrz.tu-chemnitz.de;2012-11-06 21:00:14;0427a9bd27e8ccacd2574b8435721e76 X-Spam-Score: -1.0 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP --- Ende Textanalyse 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/msg00127.txt.bz2 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 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. Why? As soon as a single bit changes somewhere, the only formally correct response from a frontend is to re-fetch everything. 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. [...] > 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. 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. Andre'