From: "Marc Khouzam" <marc.khouzam@ericsson.com>
To: "Vladimir Prus" <vladimir@codesourcery.com>,
<gdb-patches@sources.redhat.com>
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 [thread overview]
Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA0774F944@ecamlmw720.eamcs.ericsson.se> (raw)
In-Reply-To: API-LINK-67b69d5ca3b375525be9f427285f9670ea90ca37
> -----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
prev parent reply other threads:[~2009-05-20 14:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-28 20:04 Marc Khouzam
2009-05-01 12:00 ` Nick Roberts
2009-05-01 13:53 ` Marc Khouzam
2009-05-02 23:09 ` Nick Roberts
2009-05-04 17:26 ` Marc Khouzam
2009-05-05 11:20 ` Nick Roberts
2009-05-04 17:54 ` Vladimir Prus
2009-05-04 17:56 ` Marc Khouzam
2009-05-07 19:28 ` Marc Khouzam
2009-05-17 7:14 ` Vladimir Prus
2009-05-20 14:32 ` Marc Khouzam [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6D19CA8D71C89C43A057926FE0D4ADAA0774F944@ecamlmw720.eamcs.ericsson.se \
--to=marc.khouzam@ericsson.com \
--cc=gdb-patches@sources.redhat.com \
--cc=vladimir@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox