This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Re: [Patch] [MI] Out-of-scope varObjects no longer trigger a var-update change


 

> -----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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]