Re: [MI non-stop 10/11] Skip varobj in running threads.

[Vladimir Prus <vladimir at codesourcery dot com>]

On Friday 11 July 2008 17:53:35 Daniel Jacobowitz wrote:
> On Sat, Jun 28, 2008 at 09:00:06PM +0400, Vladimir Prus wrote:
> > 
> > If a variable object is bound to a specific thread, and we're doing
> > 
> >   -var-update *
> > 
> > and varobj's thread is running, we cannot update varobj -- so we skip it.
> > Will commit when core non-stop is in.
> 
> I think this needs to go in the manual.  Would it be helpful to
> indicate to the front end that a variable could not be updated due to
> a running thread?

Possibly -- the frontend may want to decorate varobj from running threads
in specific ways. OTOH, until non-stop frontends actually appear, we don't
know exact requirements, so I'd prefer to introduce bare minimum -- which
is not falling over trying evaluate expressions in running threads.

> If a varobj is bound to a particular thread that usually means it's
> bound to a particular frame, right?  

Yes. Assuming non-always-a-thread targets do not exist, varobj is bound to a 
particular thread if and only if it's bound to some frame.

> In which case reading it while 
> the target is running doesn't make (much) sense, so there's nothing
> target specific about this.

Right. Even if target can technically access memory of a running thread,
there's no way to evaluate such a varobj since we don't have no stack.

> > +	  if (thread_id == 0 && is_executing (inferior_ptid))
> > +	    thread_running = 1;
> > +	  else if (thread_id > 0)
> > +	    {
> > +	      struct thread_info *tp = find_thread_id (thread_id);
> > +	      if (tp)
> > +		thread_running = is_running (tp->ptid);
> > +	    }
> 
> Why is_running in one place and is_executing in the other?

It's a mistake, should be is_running.

> Should we try reading from something besides inferior_ptid for unbound
> varobjs?

The current MI/non-stop design assumes that commands are executed in a
specific thread. If it's running, and command needs to access target, we get
an error. This is more predictable than picking random thread. Some targets,
like break, can implicitly use the current frame, and switching to random
thread will make them behave erratically.

- Volodya