From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32005 invoked by alias); 7 Nov 2012 18:54:23 -0000 Received: (qmail 31996 invoked by uid 22791); 7 Nov 2012 18:54:22 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Nov 2012 18:54:18 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qA7IsBj7014395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Nov 2012 13:54:11 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qA7Is9lW000480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 7 Nov 2012 13:54:10 -0500 From: Tom Tromey To: Marc Khouzam Cc: "'Pedro Alves'" , "=?utf-8?Q?'Andr=C3=A9_P=C3=B6nit?= =?utf-8?Q?z'?=" , "'Yao Qi'" , "'gdb-patches\@sourceware.org'" 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> <5098A88B.5070005@codesourcery.com> <20121106200012.GA2591@klara.mpi.htwm.de> <509A93C0.9020009@redhat.com> Date: Wed, 07 Nov 2012 18:54:00 -0000 In-Reply-To: (Marc Khouzam's message of "Wed, 7 Nov 2012 18:18:18 +0000") Message-ID: <87sj8li6r2.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/msg00162.txt.bz2 >>>>> "Marc" == Marc Khouzam writes: Marc> Since GDB allows the frontend to try to avoid a full Marc> refresh by giving extra information in its notifications, Marc> the idea of continuing with that approach seemed the right one. Marc> For instance, GDB could have a single =breakpoints-changed Marc> notif which would trigger a full refresh a breakpoints. Marc> Same for variable objects (see -var-update). Even Marc> =threads-changed (although this may be a little more Marc> justified if we think about it more deeply). In some cases, like breakpoints, gdb has perfect information. In these situations, sending small changes is easy and efficient. For memory or registers, I think the PR established pretty clearly that gdb doesn't have perfect information, or at the very least, that trying to compute it perfectly would be a lot of work, and so it is preferable to avoid doing so if possible. For varobjs, gdb caches the previously sent data so that it can send deltas. I think this could be done with other the entities in question -- registers, memory, stack frames -- if the communications overhead of a full update is the rate-limiting step. On the other hand, if the computation in gdb (including communication with the inferior) is rate-limiting, then this won't help at all. Threads are a kind of funny case, see the "finding new threads in the inferior" item here: http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity Tom