This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI non-stop interface details

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"?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]