Re: MI non-stop mode spec

[Nick Roberts <nickrob@snap.net.nz>]

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

I used pid_to_thread_id (inferior_ptid) for the thread_id, just as
infrun.c does for *stopped.  I think that the thread_id problem for
single/multi-threaded programs should be fixed first (perhaps along the
lines Daniel suggested).


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

Perhaps we're miscommunicating.  I mean if the user wants the variable object
to "float" with the selected frame, he can't change threads because GDB will
forget which frame was the selected frame.  In other words, I think that, in a
stateful GDB, get_selected_frame needs to be fixed.

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