From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21824 invoked by alias); 15 Jan 2008 19:36:14 -0000 Received: (qmail 21811 invoked by uid 22791); 15 Jan 2008 19:36:13 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 Jan 2008 19:35:49 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m0FJZmAI017012 for ; Tue, 15 Jan 2008 13:35:48 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 13:35:47 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: -var-update using formatted value Date: Tue, 15 Jan 2008 19:36:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04290E35@ecamlmw720.eamcs.ericsson.se> In-Reply-To: A From: "Marc Khouzam" To: 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: 2008-01/txt/msg00113.txt.bz2 > > However, in my case, where we work with embedded systems and we want to > > minimize the requests to the (potentially very slow) back-end, I was > > hoping to share the same variable > > object and to cache the value of each format. > >=20 > I don't understand the above. Changing format of a variable object is not > supposed to refetch if from the target, so caching string representation > on frontend side is not necessary. I'm not sure what you mean. If I have a varObject displaying 0x1 in hex and then I want to show the val= ue in binary, I will need to go to the target. If I cache both those values in the frontend, then I was hoping to rely on var-update to let me know if my cache is still valid, for any formats not just the last one I used. > > -var-create - * z (print value is remembered to be 11) > > -var-set-format var1 hex > > -var-evaluate-expression var1 =3D> Oxb > > -exec-step > > -var-update var1 =3D> will show var1 to have changed >=20 > As I've said before, it's a bug -- -var-set-format should recompute the s= tored > value.=20 This one may not really be a true bug. The real bug is is not showing a ch= ange when there is one in evaluate-expression. In this case, it is superfluous.= .. The code has a comment about var-update being an approximation (in the case of a double var-assign, where this can also happen): /* If the value has changed, record it, so that next -var-update can report this change. If a variable had a value of '1', we've set it to '333' and then set again to '1', when -var-update will report this variable as changed -- because the first assignment has set the 'updated' flag. There's no need to optimize that, because return value of -var-update should be considered an approximation. */ (from varobj.c) > 1. Make -var-evaluate-expression directly return stored printed value > 2. Make -var-set-format recompute the stored printed value. Sounds good. Although the second change would have an interesting impact; if a front-end= =20 sends a var-set-format but does not follow it by a var-evaluate-expression. The front-end would not know about the latest printed value, but var-update would not show a change from the last var-evaluate-expression (the one of t= he old format and that the frontend does know about.)=20=20 But this could be considered a bug in the frontend.