From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29889 invoked by alias); 14 Jan 2008 02:36:35 -0000 Received: (qmail 29879 invoked by uid 22791); 14 Jan 2008 02:36:34 -0000 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jan 2008 02:36:12 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m0E2aAfc029337 for ; Sun, 13 Jan 2008 20:36:10 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Jan 2008 20:36:10 -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: -var-update using formatted value Date: Mon, 14 Jan 2008 02:36:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA2DE08C@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA04290E1B@ecamlmw720.eamcs.ericsson.se> <18311.60638.724524.220449@kahikatea.snap.net.nz> <20080111225928.GA26360@caradoc.them.org> <18311.65093.38930.103045@kahikatea.snap.net.nz> <20080111235219.GA29698@caradoc.them.org> <6D19CA8D71C89C43A057926FE0D4ADAA2DE08B@ecamlmw720.eamcs.ericsson.se> <20080112034900.GA8947@caradoc.them.org> 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/msg00093.txt.bz2 > > For example, in your example of strings changing from=20 > > natural value: 0x804a018 "GNU" to > > natural value: 0x804a018 "GDB" > > If the variable object tracking this has its format set to anything els= e than natural, > > the actual string is not printed and the value seems to stay the same so > > -var-update will not detect the change in value. >=20 > That is deliberate. I reread your message, and I still can't see a > good reason for -var-update to report a changed variable if > -var-evaluate-expression is going to continue to display it the same > way, i.e. as if no update has occurred. If you're worried about > multiple formats, maybe you should keep a varobj for each instead of > switching one around? I had assumed var-update to be an indication of when the actual content of = a variable has changed. Although, truth be told, the documentation is clear that var-= update will trigger only if -var-evaluate-expression changed (for the current format.)= =20 And I do see your point for this logic. You are right that my issue is with multiple formats and your suggestions o= f different variable objects would work fine. However, in my case, where we work with embedded systems and we want to min= imize 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. This use-case requires a var= -update that will indicate if a value has changed in any format, not just the curre= nt one, so as to know to invalidate the cache. But I believe I can achieve this by setting the format to natural before ev= ery -var-update, which I have to do anyway until the -var-update fix for binary numbers and = floats (please see other bug description below) is available. For the sake of completeness, let me just point out that the current var-up= date implementation can often show a change when var-evaluate-expression still displays the sam= e thing. This is because the stored 'print_value' is not updated with each -var-evaluate-exp= ression request e.g., int z =3D 0xb; -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 becau= se it compares it to 11 and not 0xb -var-evaluate-expression var1 =3D> Oxb =20=20=20=20 but as I said, I'm only mentioning this for the sake of completeness, I per= sonally don't think it is a big deal. However, I do want to point to another example of the bug that originated t= his discussion, which will -not- be fixed by using the 0b prefix for binary. I noticed that GDB prints floating point numbers such as "1.0" as "1". Thi= s can cause the same problem as the binary example. int main() { double d =3D 1.99;=20 int a =3D 0; // line 3 d =3D 1.0; } program stopped on line 3 -var-create d * d ^done,name=3D"d",numchild=3D"0",value=3D"1.99",type=3D"double" (gdb)=20 -var-set-format d dec ^done,format=3D"decimal" (gdb)=20 -var-evaluate-expression d ^done,value=3D"1" (gdb)=20 next ^done (gdb)=20 -var-update d ^done,changelist=3D[{name=3D"d",in_scope=3D"true",type_changed=3D"false"}] = =3D> superfluous (gdb)=20 -var-evaluate-expression d ^done,value=3D"1" (gdb)=20 -var-set-format d nat ^done,format=3D"natural" (gdb)=20 -var-evaluate-expression d ^done,value=3D"1.99" (gdb)=20 next ^done (gdb)=20 -var-update d ^done,changelist=3D[] =3D> missing (gdb)=20 -var-evaluate-expression d ^done,value=3D"1" The same type of fix as the 0b prefix for binary numbers can be used here, = where floats should always show the decimal point even if followed by only a 0. "1.0" cannot be shown as "1" in natural but always as "1.0". Again, side-effects of such a solution are unknown to me. Marc