This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: Re: [Patch] [MI] Out-of-scope varObjects no longer trigger a var-update change
- From: "Marc Khouzam" <marc dot khouzam at ericsson dot com>
- To: "Vladimir Prus" <vladimir at codesourcery dot com>, <gdb-patches at sources dot redhat dot com>
- Date: Wed, 20 May 2009 10:31:36 -0400
- Subject: RE: Re: [Patch] [MI] Out-of-scope varObjects no longer trigger a var-update change
- References: <6D19CA8D71C89C43A057926FE0D4ADAA0759C401@ecamlmw720.eamcs.ericsson.se> A<guodg3$ebt$1@ger.gmane.org>
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org
> [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
> trigger a var-update change
>
> Marc Khouzam wrote:
>
> > Hi,
> >
> > I believe a small bug slipped in the refactoring of varobj_update
> > interface from:
> > http://sourceware.org/ml/gdb-patches/2008-05/msg00106.html
> >
> > 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.
> >
> > The MI part of the testsuite passed ok.
> > I have an test to trigger the bug, if you care to see it.
> >
> > Ok?
> >
> > 2009-04-28 Marc Khouzam <marc.khouzam@ericsson.com>
> >
> > * varobj.c (varobj_update): Push an out-of-scope
> > variable object on the result vector.
> >
> > Index: gdb/varobj.c
> > ===================================================================
> > 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 == NULL)
> > r.status = VAROBJ_NOT_IN_SCOPE;
> >
> > - if (r.type_changed || r.changed)
> > + if (r.type_changed || r.changed || r.status ==
> > VAROBJ_NOT_IN_SCOPE)
> > VEC_safe_push (varobj_update_result, result, &r);
>
> I am afraid this patch is not right for two reasons:
>
> 1. A varobj that is not in scope will be always reported
> as changed:
>
> (gdb)
> -var-update S
>
> ^done,changelist=[{name="S",in_scope="false",type_changed="false"}]
> (gdb)
> -var-update S
>
> ^done,changelist=[{name="S",in_scope="false",type_changed="false"}]
> (gdb)
>
> This behaviour almost patches GDB 6.8 (it did not print
> 'type_changed'), but is
> not right.
I never noticed this. I guess it never came up because as soon as
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
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
> as changed:
>
> (gdb)
> s
> &"s\n"
> ^running
> *running,thread-id="1"
> (gdb)
> ~"foo () at a.c:7\n"
> ~"7\t s.i = 10;\n"
> *stopped,....
> (gdb)
> -var-update S
> ^done,changelist=[]
> (gdb)
>
>
> This does not match GDB 6.8 -- which continues to claim 'S'
> 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
> right in both cases. Let
> me know if that works for you.
Yes, my Junit tests now pass.
Thanks!
Marc