Re: MI non-stop mode spec

[Pawel Piech <pawel dot piech at windriver dot 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