This is the mail archive of the
mailing list for the GDB project.
Re: MI non-stop interface details
- From: Pawel Piech <pawel dot piech at windriver dot com>
- To: gdb at sourceware dot org
- Date: Mon, 28 Apr 2008 10:52:13 -0700
- Subject: Re: MI non-stop interface details
- References: <email@example.com>
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.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.
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.
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]"...
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.
This is a good compromise, would there be a special "reason" value, such
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
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.