Re: MI non-stop mode spec

[Vladimir Prus <vladimir at codesourcery dot com>]

On Wednesday 19 March 2008 00:16:01 Vladimir Prus wrote:

> MI commands changes
> -------------------
>
>     (**) There are two new options that a number of MI commands may
> take:
>
>           --thread <id>
>
>     option specifies the id of the thread the command should operate
> on.
>
>            --global
>
>     specifies that the command should operate on no thread, but on
>     global data.  This option is necessary to distinguish the case
> where the frontend has forgot to specify --thread, assuming that the
> current thread will be used, from the case when frontend explicitly
> wants to execute a command in global scope.  This clarify of
> intention is particularly important when the "current thread" is
> running.

It seems like I have over-engineered this one. The --global option
was meant so that we can evaluate expressions while the target is 
running, but:

- Generally, we cannot access target memory when all threads are
running
- GDB is full with assumptions that we have current thread and current
frame, so even if target can access memory when all threads is running,
gdb will still try to grab selected frame, and that will try to grab
target's register, and that will result in error.

So, I'd like to remove the --global option. This means that the --thread
option must be used to specify which thread to operate on, and that
thread must be stopped.

In fact, a mechanism to evaluate expression in an arbitrary scope 
(including global scope) might be actually good. Now, implementing
variable tooltips via MI is impossible, as we cannot evaluate an
expression in a given scope (defined by source line). However, that
appears to be orthogonal issue to the non-stop mode.

- Volodya