This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop mode spec
- From: Pawel Piech <pawel dot piech at windriver dot com>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 21 Mar 2008 11:12:34 -0700
- Subject: Re: MI non-stop mode spec
- References: <200803190016.02072.vladimir@codesourcery.com>
Hi Vladimir,
Thank you for putting together this proposal for extending the MI
protocol to allow non-stop debugging. In general I think the changes
you are proposing are positive I just have two criticisms when looking
at this proposal from the client's point of view. BTW, I work with Marc
on the Eclipse DSF-GDB integration. One disclaimer I should make is
that I'm not familiar with any of the GDB internals so I don't know what
is easier/more difficult. I'm only speaking from a client's point of view.
1) Changing the protocol to be (partially) stateless by adding -thread
and -global options to multitude of commands is not backwards compatible.
From the clients point of view, keeping the protocol backward
compatible is a great benefit. I'm not a big fan of -thread-select, but
it's there and trying to remove it now I think will cause more problems
than it solves.
You mentioned that when switching to non-stop mode there is an inherent
race condition in using -thread-select because GDB may switch current
threads due to an async stopped event. A less jarring change to the
protocol than adding -thread/-global to all the commands would be to
change the behavior of *stopped not to switch the current thread. To
remain backward compatible with older GDB versions, i.e. to work with
old *stopped event behavior, MI clients can make the assumption that
after a stopped event the current thread is not known and send a
-thread-select before sending new commands. One objection to this
change may be that it's not forward compatible and older clients will
not work with the new MI protocol version, but I think older clients
will not work with GDB in non-stop mode anyhow with the protocol changes
that you propose, so that point should make no difference in your decision.
I don't fully understand why disabling CLI commands is desired, but I'm
guessing it's because the CLI commands would still rely on the current
thread. If so, then keeping the MI protocol stateful would hopefully
address that concern and not force you to disable the CLI interface,
which would be unfortunate.
2) The proposal does not address multi-process debugging in any way. I
understand that multi-process (or multi-core) debugging is not part of
this proposal, but I think keeping that use case in mind when making
this change would make it less painful for the clients when we actually
get to that point. In context of multi-process debugging, options such
as -global and fields such as "all" are rather ambigeous. Instead, I
have the following suggestion:
Assign an ID to a process in the same name space as threads. Until
multi-process debugging is implemented you could just reserve a thread
id, such as "0" to be the process thread ID. For completeness this ID
would be returned already in the thread-id field of the response to
-target-select command In order to operate on a whole process context
use a -thread-select command with the process context id (followed by
the command). -thread-list-ids would list threads within that process,
normally starting with "1". In reporting stopped events, (in non-stop
debugging mode) if a thread has suspended, use the thread-id field to
indicate which thread has triggered the stop. Use a separate field:
container-id, to indicate whether the whole process stopped, assuming
that some events still cause all threads to stop. In all-stop mode, the
container-id field would always be present in the stopped event. I
think that making this change would allow clients to still work with
older versions of GDB in all-stop mode, since thread 0 in all-stop mode
would act like a container thread anyway, resuming and suspending all
threads.
The Wind River debugger which implements the MI protocol, supprots
multi-core/multi-process debugging, non-stop and all-stop debugging
modes simultaneously (for different targets), uses the above protocol
extensions for several years now rather successfully. So I hope you
consider these suggestions seriously even if they are not easiest to
implement given the GDB architecture.
Cheers,
Pawel