Re: MI non-stop interface details

[Pawel Piech <pawel.piech@windriver.com>]

Vladimir,
Thank you for the update and thank you for incorporating our feedback in 
your proposal.  Having continued support for thread-select will make for 
a much smoother transition to this version of protocol.  I only have a 
couple of comments below:

Vladimir Prus wrote:
> There are a couple of open questions.
>
> 1. Presently, -exec-continue resumes all threads, and the current thread
> has no effect. I think it's desirable to be able to resume a single thread,
> and for that, we actually need the --thread option for -exec-continue, to
> mean that a single thread must be resumed.
> 2. Presently, -exec-step also resumes all threads. There's an option,
> "scheduler-locking" that can be used for cause -exec-step to resume only
> the current thread. It seems to be, that for non-stop mode, resuming all
> threads is a wrong thing to do, therefore -exec-step, when in non-stop
> mode, will resume only the thread been stepped. This will be the same
> no matter if the thread is specified implicitly or explicitly.
>   
I agree with Pedro Alves that having the behavior for -exec-* be 
consistent would be very helpful.  I would also suggest '-exec-continue 
--thread="all" '.  Now if we'd be able use '-thread-select all', that 
would be even better... though I suspect you'll see lots of 
implementation issues with that.

In either non-stop or all-stop mode, I expected to see extensions to the 
*stopped and *running events, which would indicate to the client whether 
one or all threads were resumed.  If you want to be very forward looking 
you could use:
*stopped,thread-id="2",thread-ids=[2, 3, 5],container-ids="[all]"...
where :
thread-id - Indicates the the thread that triggered the event, which is 
usually the thread that should receive the focus in the UI.
thread-ids - List of all threads that were suspended, threads that are 
part of the container that stopped would be omitted.
container-ids - list of containers (cores/processes/etc) that 
suspended.  Until multi-process support is implemented, "all" would be 
the only possible value.  Empty if only the thread suspended.


> Inferior function calls
> -----------------------
>
> We already have the *stopped async event, and I have a patch to introduce the
> *running async event. Those are not emitted when doing inferiour function calls,
> since doing so may cause a frontend to infinitely refresh its state. I propose
> the following mechanism to enable those notifications for frontends that
> are sufficiently robust:
>
> 1. Declare that MI might have some features that are not enabled by default.
> 2. Introduce new command -enable-feature, which takes a name of feature and enables
> it. 
> 3. Make up a name of a feature, say inferior_call_notifications, and add that
> feature to the output of -list-features.
> 4. Make '-enable-feature inferior_call_notification' enable *running and *stopped
> for inferiour function calls.
>
> Any comments?
>   
This is a good compromise, would there be a special "reason" value, such 
as "evaluate"?

Thanks,
Pawel