From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1858 invoked by alias); 20 May 2009 14:32:27 -0000 Received: (qmail 1849 invoked by uid 22791); 20 May 2009 14:32:25 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_16,J_CHICKENPOX_17,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 14:32:14 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n4KEW9nI002660; Wed, 20 May 2009 09:32:09 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:31:38 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Re: [Patch] [MI] Out-of-scope varObjects no longer trigger a var-update change Date: Wed, 20 May 2009 14:32:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA0774F944@ecamlmw720.eamcs.ericsson.se> In-Reply-To: A References: <6D19CA8D71C89C43A057926FE0D4ADAA0759C401@ecamlmw720.eamcs.ericsson.se> A From: "Marc Khouzam" To: "Vladimir Prus" , 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: 2009-05/txt/msg00416.txt.bz2 =20 > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Vladimir Prus > Sent: May-17-09 3:14 AM > To: gdb-patches@sources.redhat.com > Subject: Re: [Patch] [MI] Out-of-scope varObjects no longer=20 > trigger a var-update change >=20 > Marc Khouzam wrote: >=20 > > Hi, > >=20 > > I believe a small bug slipped in the refactoring of varobj_update > > interface from: > > http://sourceware.org/ml/gdb-patches/2008-05/msg00106.html > >=20 > > From what I see, varobj that are not in scope don't get flagged > > as changed, because nothing was being pushed on the result vector. > > The attached patch fixes this. > >=20 > > The MI part of the testsuite passed ok. > > I have an test to trigger the bug, if you care to see it. > >=20 > > Ok? > >=20 > > 2009-04-28 Marc Khouzam > >=20 > > * varobj.c (varobj_update): Push an out-of-scope > > variable object on the result vector. > >=20 > > Index: gdb/varobj.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /cvs/src/src/gdb/varobj.c,v > > retrieving revision 1.126 > > diff -u -r1.126 varobj.c > > --- gdb/varobj.c 10 Apr 2009 16:00:49 -0000 1.126 > > +++ gdb/varobj.c 28 Apr 2009 19:49:24 -0000 > > @@ -1188,7 +1188,7 @@ > > if (new =3D=3D NULL) > > r.status =3D VAROBJ_NOT_IN_SCOPE; > >=20=20 > > - if (r.type_changed || r.changed) > > + if (r.type_changed || r.changed || r.status =3D=3D > > VAROBJ_NOT_IN_SCOPE) > > VEC_safe_push (varobj_update_result, result, &r); >=20 > I am afraid this patch is not right for two reasons: >=20 > 1. A varobj that is not in scope will be always reported > as changed: >=20 > (gdb) > -var-update S >=20=20=20=20=20=20=20=20=20 > ^done,changelist=3D[{name=3D"S",in_scope=3D"false",type_changed=3D"false"= }] > (gdb) > -var-update S >=20=20=20=20=20=20=20=20=20 > ^done,changelist=3D[{name=3D"S",in_scope=3D"false",type_changed=3D"false"= }] > (gdb) >=20 > This behaviour almost patches GDB 6.8 (it did not print=20 > 'type_changed'), but is > not right. I never noticed this. I guess it never came up because as soon as=20 we see an out-of-scope update, we delete that object. I wonder if it is safe to change this behavior. It somehow feels safer that if a frontend updates an out-of-scope object again, GDB would remind=20 the frontend that an object is out-of-scope, just in case. But I have nothing to back this claim :-) And the new behavior works well with DSF-GDB and is more elegant, so I like it. > 2. When a varobj enters the scope again, it won't be reported=20 > as changed: >=20 > (gdb) > s > &"s\n" > ^running > *running,thread-id=3D"1" > (gdb) > ~"foo () at a.c:7\n" > ~"7\t s.i =3D 10;\n" > *stopped,.... > (gdb) > -var-update S > ^done,changelist=3D[] > (gdb) >=20 >=20 > This does not match GDB 6.8 -- which continues to claim 'S'=20 > is out of scope. Both > the above, and GDB 6.8 are clearly in error. I was not able to reproduce this behavior with GDB 6.8. When stepping back into a method, I saw var-update report that the object was in-scope again. But your patch also does that, so it is good for me. > I have checked in the below that makes -var-update bahave=20 > right in both cases. Let > me know if that works for you. Yes, my Junit tests now pass. Thanks! Marc