This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: per-thread variable objects
On Monday 24 March 2008 23:59:20 Nick Roberts wrote:
> > I've checked it the following revision of Nick's previous
> > patch (http://permalink.gmane.org/gmane.comp.gdb.devel/22707) that
> > makes variable object remember the thread they belong to.
> > I've tested this manually, proper thread and docs will be following
> > shortly.
> >
> > Nick,
> > the changes I've made are as follows:
> >
> > - I use the valid_block instead of special -2 value
> > to check if a varobj is global.
> > - I did not use -1 value to indicate the thread is gone. Presently,
> > we don't specifically mark variables object whose frame is gone,
> > and I don't see why we should be do differently for threads.
> >
> > If something seems wrong, please say.
>
> It would be nice to reach an agreement before the changes are commmitted.
You are right; I apologise for rushing to cross an item from my todo list.
> > Index: gdb/ChangeLog
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/ChangeLog,v
> > retrieving revision 1.9247
> > diff -u -p -r1.9247 ChangeLog
> > --- gdb/ChangeLog 23 Mar 2008 17:29:32 -0000 1.9247
> > +++ gdb/ChangeLog 24 Mar 2008 17:31:09 -0000
> > @@ -1,3 +1,15 @@
> >...
>
> I think ChangeLog entries shouldn't be presented as diffs.
Does that cause any practical issue to anybody?
> >...
> > +/* If frame associated with VAR can be found, switch
> > + to it and return 1. Otherwise, return 0. */
>
> It's not enough for a frame to be found, the pc also has to have an address
> value within the valid block. This is one reason why, for such small
> functions, I would rather the code spoke for itself.
To be honest, the checking for block boundaries cries for comments too.
It's not really appparent why we check for it, and importantly -- should
variables not in the current block be reported as "out of scope", or
reported in some other way.
- Volodya