This is the mail archive of the gdb@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: -var-list --locals proposal


On Tue, Jan 16, 2007 at 10:00:44AM +0300, Vladimir Prus wrote:
> > I think most of the complexity in this will come from reusing varobjs.
> > Couldn't we do this with -var-update?  The meaning of in_scope="false"
> > is a bit unclear today, since we use it for anything whose value we
> > can't find, and in optimized code a variable can go in and out of
> > scope.  So using that might not be a good idea.  We could add another
> > marker, though, such as frame_exited="true" to indicate that a varobj's
> > associated frame has returned (or otherwise disappeared from the
> > stack).  A varobj would never transition from frame_exited="true" to
> > frame_exited="false".
> 
> I think it would be good to reuse varobj accross the frames. So,
> if you're in some function and look at its locals and then enter
> another function and try to look at parents variables you get
> the same varobjs. I don't think that creation of varobj is 
> so expensive in gdb itself -- but for frontend it's more
> convenient to always have the same varobj associated with 
> a variable.

But, if we can export frame IDs in some safe and useful way to the
frontend, we can avoid having to recreate them at all.  The front
end would just know that they were the same, and not reissue -var-list.

I think I saw something about frame events on gdb-patches but I'm not
going to try to catch up on that list until the weekend, I think.

-- 
Daniel Jacobowitz
CodeSourcery


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