From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23383 invoked by alias); 28 Mar 2012 08:03:28 -0000 Received: (qmail 23184 invoked by uid 22791); 28 Mar 2012 08:03:20 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail76.messagelabs.com (HELO mail76.messagelabs.com) (216.82.242.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Mar 2012 08:03:05 +0000 X-Env-Sender: jens.elmenthaler@verigy.com X-Msg-Ref: server-16.tower-76.messagelabs.com!1332921783!23631399!2 X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18538 invoked from network); 28 Mar 2012 08:03:04 -0000 Received: from ahmler2.mail.eds.com (HELO ahmler2.mail.eds.com) (192.85.154.72) by server-16.tower-76.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Mar 2012 08:03:04 -0000 Received: from ahmler2.mail.eds.com (localhost.localdomain [127.0.0.1]) by ahmler2.mail.eds.com (8.14.4/8.13.8) with ESMTP id q2S82mel024833; Wed, 28 Mar 2012 04:02:48 -0400 Received: from ahbir2.mail.eds.com (ahbir2-2.mail.eds.com [192.85.154.140]) by ahmler2.mail.eds.com (8.14.4/8.13.8) with ESMTP id q2S82lTP024647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Mar 2012 04:02:48 -0400 Received: from USPLSVPEX002.ent.rt.verigy.net ([192.100.40.8]) by ahbir2.mail.eds.com (8.13.8/8.13.8) with ESMTP id q2S82luh017754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Mar 2012 04:02:47 -0400 X-EDSCOD-Source-Ip: 192.100.40.8 X-Envelope-From: jens.elmenthaler@verigy.com Received: from DEBOSVPEX002.ent.rt.verigy.net (10.17.10.105) by USPLSVPEX002.ent.rt.verigy.net (10.16.58.176) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 28 Mar 2012 03:02:31 -0500 Received: from DEBOSVPEX001.ent.rt.verigy.net ([169.254.3.246]) by DEBOSVPEX002.ent.rt.verigy.net ([10.17.10.105]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 10:02:45 +0200 From: "Elmenthaler, Jens" To: Tom Tromey CC: "gdb@sourceware.org" Subject: RE: [Pretty printers] Can the name or type of a child value change? Date: Wed, 28 Mar 2012 08:03:00 -0000 Message-ID: References: <58596C4646708B4BB990C4483997333002F403D9@usplmvpbe001.ent.rt.verigy.net> In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00076.txt.bz2 This actual is a return to a discussion that goes back to 1 1/2 years ago. = The question was whether a pretty printer can change the name and type of t= he returned children when stepping. Tom's answer (see bottom this email) wa= s yes. I'm now using this feature, but stumble over a very basic question: if the = name of a child changes, how does the MI variable object return this fact i= n -var-update? I don't see a tuple telling the frontend that this happened.= It seems it should be the "exp" field that is returned by -var-list-childr= en, but neither documentation nor gdb's code seems to consider it for -var-= update. Greetings, Jens. p.s For references, here the original example: Consider the following code example:=20 struct JAny {=20 union {=20 char *text;=20 int number;=20 } val;=20 // 1 -> text, 2 -> number=20 int type;=20 };=20 And the following pretty printer:=20 class AnyPrinter:=20 class _iterator:=20 def __init__ (self, name, value):=20 self.count =3D 0=20 self.name =3D name=20 self.value =3D value=20 def __iter__(self):=20 return self=20 def next(self):=20 if self.count !=3D 0:=20 raise StopIteration=20 =20=20=20=20=20=20=20=20=20=20=20=20 self.count =3D self.count + 1=20 return (self.name, self.value)=20=20=20=20=20 def __init__(self, val):=20 self.type =3D val['type']=20 =20=20=20=20=20=20=20=20 if self.type =3D=3D 1:=20 self.value =3D val['val']['text']=20 self.name =3D "text"=20 =20=20=20=20=20=20=20=20=20=20=20=20 if self.type =3D=3D 2:=20 self.value =3D val['val']['number']=20 self.name =3D "number"=20 =20=20=20=20=20=20=20=20=20=20=20=20 def children(self):=20 return self._iterator(self.name, self.value)=20 def to_string(self):=20 return "JAny"=20 When stepping in the debugger over a line that changes JAny.type, the name = and the type of the child value returned by the pretty printer change.=20 Are the MI variable objects meant to handle this?=20 -----Original Message----- From: Tom Tromey [mailto:tromey@redhat.com]=20 Sent: Monday, August 16, 2010 10:54 PM To: Elmenthaler, Jens Cc: gdb@sourceware.org Subject: Re: [Pretty printers] Can the name or type of a child value change? >>>>> "Jens" =3D=3D Elmenthaler, Jens writes: Jens> Consider the following code example: [...] Jens> When stepping in the debugger over a line that changes JAny.type,=20 Jens> the name and the type of the child value returned by the pretty=20 Jens> printer change. Jens> Are the MI variable objects meant to handle this? Yes. The MI consumer is expected to understand that dynamic varobjs are dynamic: the number and names of children can change in arbitrary ways. This is incompatible with previous expectations, which is why consumers hav= e to explicitly request this feature from gdb. Tom