Re: MI non-stop mode spec

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > 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.

 > 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?

In general I guess threads don't traverse the same frames so watch expressions
wouldn't always work for all threads. 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.



-- 
Nick                                           http://www.inet.net.nz/~nickrob