This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop mode spec
On Friday 21 March 2008 12:48:15 Nick Roberts wrote:
> > > I think there are more than three possibilities:
> > >
> > > 1) bound to the frame in which varobj is created (*).
> > > 2) bound to the selected frame (@)
> > > 3) bound to the thread in which varobj is created and 1)
> > > 4) bound to the thread in which varobj is created and 2)
> > > 5) bound to the selected thread and 1)
> > > 6) bound to the selected thread and 2)
> > >
> > > Maybe there are more, e.g, all threads (I've not really thought
> > > them through)
> > >
> > > Currently only 1) works and 2) has a broken implementation.
> >
> > Didn't you check in a patch to make *-varobjs be found to a
> > thread?
>
> I submitted a patch earlier this year that stopped thinking that a
> variable object had gone out of scope if the thread changed but
> nothing happened.
Can you resend the current version of that patch, and I'll take a look.
> > Furthermore, are (1) and (2) actually separate options? You cannot
> > evaluate varobj in a frame without also specifying a thread.
>
> Hmm, perhaps I typed that too quickly, it looks like 3-6 are just
> multi-threaded cases of 1 and 2, so there are four in total.
>
> It appears that Totalview call 1) FIXED compilation scope and 2)
> FLOATING compilation scope. Gdb calls it USE_CURRENT_FRAME and
> USE_SELECTED_FRAME which I find very confusing. Particularly (as
> I've said before) the manual mixes the meaning of current frame with
> selected frame. With USE_SELECTED_FRAME, the value can change
> without execution, e.g. after an up or down. It would be nice to
> change these enum values to USE_FIXED_FRAME and USE_FLOATING_FRAME.
> WDYT?
There's also USE_SPECIFIED_FRAME, to make the whole thing
funnier. Those values are only used in the call to varobj_create,
and struct varobj has a field named 'use_selected_frame'. Probably
the name of field of struct varobj is fine, whereas those USE_*
are badly named indeed. Maybe, the varobj_create interface should
be redone to accept a frame and a "floating" flag?
> In general I guess threads don't traverse the same frames so watch
> expressions wouldn't always work for all threads.
Right, so when user switches UI to a different thread, we get to
reevaluate watches. Something like:
-var-update --thread 2 --frame 5 @
seems like appropriate solution.
> I don't know how
> GDB would know if they did but I see that Totalview has something
> that they call a laminated view which views variables across threads
> (and processes). In fact their online manual must be a good
> guideline for some of the non-stop mode spec.
>
> Also GDB loses sense of the selected frame: if you change to a
> different thread and back again you always get back to the innermost
> (= current) frame. So that makes it difficult to get
> USE_SELECTED_FRAME to work in the multi-threaded case.
I think that the syntax mentioned above will get around that. When
GDB evaluates
-var-update --thread 2 --frame 5 @
it switches to thread (which selects frame 0) and then immediately
selects frame 5, so by the time we evaluate expression, we're
in the right thread and frame.
- Volodya