Re: MI non-stop mode spec

[Vladimir Prus <vladimir@codesourcery.com>]

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