This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop mode spec
On Saturday 22 March 2008 03:32:53 Nick Roberts wrote:
> > > > 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).
Dan's patch is in, however, it only affects Linux. I suspect in might
be a long time till the problem is solved on all system. Until then,
we probably should assume that if thread list is empty, then the
program is ST and never will become MT.
I happen to be working on variable objects for non-stop now, so I'll
play with the last version of your patch that you have posted.
> > > 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.
Maybe we're looking at it from different perspectives. I think
that frontend can, and probably should, maintain its own notion
of selected frame for each thread. Then, the @ variables can
be re-evaluated in whatever thread/frame is current from frontend
point of view.
- Volodya