From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12558 invoked by alias); 7 Nov 2012 21:09:10 -0000 Received: (qmail 12545 invoked by uid 22791); 7 Nov 2012 21:09:09 -0000 X-SWARE-Spam-Status: No, hits=-3.3 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; Wed, 07 Nov 2012 21:09:00 +0000 Received: from 91-65-60-103-dynip.superkabel.de ([91.65.60.103] helo=localhost) by cora.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1TWCro-0002dt-SL; Wed, 07 Nov 2012 22:08:57 +0100 Date: Wed, 07 Nov 2012 21:09:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Tom Tromey Cc: Marc Khouzam , 'Pedro Alves' , 'Yao Qi' , "'gdb-patches@sourceware.org'" Subject: Re: [RFC] MI notification on register changes Message-ID: <20121107210855.GA5140@klara.mpi.htwm.de> References: <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> <87sj8li6r2.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sj8li6r2.fsf@fleche.redhat.com> X-purgate: clean.bounce X-purgate-type: clean.bounce X-purgate-ID: 154106::1352322537-00000CD1-CBBDD7BC/0-0/0-18 X-Scan-AV: cora.hrz.tu-chemnitz.de;2012-11-07 22:08:57;700999528a70e197ed04c61e7ab149b5 X-Scan-SA: cora.hrz.tu-chemnitz.de;2012-11-07 22:08:57;e2d9e23b363c8742ebcd6f595b3f0fb3 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/msg00168.txt.bz2 On Wed, Nov 07, 2012 at 11:54:09AM -0700, Tom Tromey wrote: > >>>>> "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. Computing perfect updates is not possible. GDB would need to keep track of all memory locations and registers used to create the representation of the value, and even that would not be perfect in the presence of "external" sources of information like the result of system calls or similar. > For varobjs, gdb caches the previously sent data so that it can send > deltas. And this is not sufficient for proper display. Consider: In .gdbinit (or similar): python class Printer(object): def __init__(self, val): self.val = val def to_string(self): return ["foo", "bar"][int(gdb.parse_and_eval("d"))] def display_hint(self): return 'string' def P(val): if str(val.type) == "struct S": return Printer(val) return None gdb.pretty_printers = [ P ] end In main.c: int d; struct S { } s; int main() { d = 1; d = 0; d = 1; d = 0; d = 1; d = 0; d = 1; d = 0; d = 1; d = 0; d = 1; } With "full refetch" you get alternating values for s when stepping: (gdb) display d 1: d = 0 (gdb) display s 2: s = "foo" (gdb) n 41 d = 0; 2: s = "bar" 1: d = 1 (gdb) 42 d = 1; 2: s = "foo" 1: d = 0 (gdb) 43 d = 0; 2: s = "bar" 1: d = 1 (gdb) 44 d = 1; 2: s = "foo" 1: d = 0 (gdb) 45 d = 0; 2: s = "bar" 1: d = 1 (gdb) Using MI varobj's you can get something like that: (gdb) -var-create d * d ^done,name="d",numchild="0",value="0",type="int",has_more="0" (gdb) -var-create s * s ^done,name="s",numchild="0",value="{...}",type="struct S",has_more="0" (gdb) n ^running *running,thread-id="all" (gdb) ~"39\t d = 0;\n" *stopped,frame={addr="0x080483e9",...,line="39"},.... (gdb) -var-update * ^done,changelist=[{name="d",in_scope="true",type_changed="false",has_more="0"}] (gdb) n ^running *running,thread-id="all" (gdb) ~"40\t d = 1;\n" *stopped,frame={addr="0x080483e9",...,line="40"},.... (gdb) -var-update * ^done,changelist=[{name="d",in_scope="true",type_changed="false",has_more="0"}] Only the changes to d are announced. For the frontend there is no indication whatsoever that the display of s would need to be updated. The only way to get the proper alternating display is to fully refetch everything again: (gdb) p s &"p s\n" ~"$1 = \"foo\"\n" ^done (gdb) p d &"p d\n" ~"$2 = 0" ~"\n" ^done (gdb) n &"n\n" ^running *running,thread-id="all" (gdb) ~"41\t d = 0;\n" *stopped,frame={addr="0x080483fd",...,line="41"},.... (gdb) p s &"p s\n" ~"$3 = \"bar\"\n" ^done (gdb) Andre'