Some comments from the DSF frontend point-of-view:

> So, I propose to remove the prompt right after ^running for the 
> sync targets.

DSF also ignores the "(gdb)", except at startup when it uses it
to know GDB is ready.

> (*) Currently, the *stopped output does include the token of
> the last command.  However, it's implemented in limited way --
> if we allow any command except for -exec-interrupt in async
> mode, the token printed for *stopped will be wrong. In non-stop
> mode, associating *stopped with a command is just impossible.

DSF ignores the token for all out-of-band events, so removing
it from *stopped shouldn't be a problem.


> To simplify things, if GDB is started in MI mode, no CLI command is allowed
> while the target is running, and -interpreter-exec is not allowed either.

This would mean that unless all threads are stop, the user will not be able
to use the CLI on top of MI.  It would be nice if the user could interact
with the stopped threads using the CLI, although, I agree with you, that
this needs to be done carefully.  

>    (**) 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.

Does this mean that MI will still accept commands without --thread or --global,
and interpret them to mean 'use current thread'?
For some reason, I don't like that too much.  I think the frontend should
always use --thread or --global, so we make sure the frontend did not really
'forget' to specify the thread. (I'm not considering any backwards compatibly
issues here.)
But it would be nice to have a way to specifically indicate to use  the current
thread.  Maybe a special thread id could be used ( - or * for example).


>    - Thread commands. The -thread-info command should be implemented (a
>    patch is already posted).
>    (**) The -thread-list-all-threads is not necessary with the current
>    behaviour of -thread-info.
>    (**) The -thread-select command is only allowed on the that that is
>    currently stopped.  This command should not generally be used in
>    non-stop mode.

As suggested above, if we always use --thread or --global, then
-thread-select could be removed -entirely.  Or, it could be disabled in
non-stop mode, if it really should be kept for all-stop mode (although I
don't think it does; but again, not considering backward compatibility.)
   
>    - Program execution. The -exec-next, -exec-step, -exec-finish, 
>    -exec-until, -exec-return, -exec-step-instruction and 
>    -exec-next-instruction command require --thread parameter. Also,
>    those commands resume strictly the thread that is being stepped,
>    equivalent to "scheduler-locking on". 
>    The -exec-continue command with the --thread parameter will resume
>    just one thread, whereas -exec-continue without a --thread parameter
>    will resume all threads that are not presently running.

Again, I get the feeling we should always use --thread.  But I would
like your opinion on that.  We could have 'all' as a thread id, or use
--global for -exec-continue all threads.


>   -> Should @ varobjs be bound to only thread, or to nothing at all.

This is an interesting question.  It brings the possibility of supporting
both those options.  That would mean three types of variable objects:
1- bound to a frame
2- bound to a thread
3- not bound

DSF does not make use of @ variable objects, so I don't know what would be
more useful between #2 and #3.
    

Regards,

Marc
�&���z۫�}x�yb�֫r