Re: MI non-stop mode spec

[Vladimir Prus <vladimir at codesourcery dot com>]

On Friday 21 March 2008 21:12:34 Pawel Piech wrote:
> 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. 

Note that --global option is not longer proposed.

>  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.

So, we have establishes that current GDB behaviour just is not suitable
for non-stop mode. It can be changed in two ways:

- Making GDB never change the current thread on its own
- Adding --thread option

I think both options require about same amount of work for frontend. In
the first case, the frontend will have to switch to the thread on *stopped.
In the second case, the frontend will have to add the --thread option to MI
commands -- and I suspect that such a change will be very local.

Both options, if implemented unconditionally, will break old frontends, so
we probably need an explicit way to enable new behaviour. In order
to allow new frontends to talk to both old and new GDB, the frontend should
be able to query for support of the new behaviour -- and we have the 
-list-features command for that.

My conclusion is that the effect on compatibility and the implementation
effort on the frontend side are basically the same, so we can judge the
alternatives based on how good they are from the protocol standpoint.

I think I still prefer --thread, as it allows the frontend to eventually
get rid of all the change-thread-do-operation-restore-thread logic. The
other alternative is less clean -- it means that there will be actually
three "current threads". One is the current thread from the frontend POV.
Another is the current thread variable that is implicitly used by most
of gdb codebase (which necessary changes as gdb works). The last is
the "current thread" for MI commands. Having those 3 current threads
and keeping those in sync sounds nasty.

> 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.

The reason I've proposed postponing CLI support is purely practical. Right now,
GDB explicitly decides which commands are allowed while the target is running.
In order to enable each specific command, one should:

  - decide what restrictions, if any, that command should have
  - actually try that command, and make sure GDB works fine, that is does
  not try to access frames in running threads, and so on.

This takes time. 

The problem of implicit thread switch is not so bad, because user typing
commands in GDB console probably waits for result of each one before
typing next. 

I guess I probably can enable the -interpreter-exec command for MI,
with the big warning that any given CLI command might not work. 

> 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.  

Can we rename 'container-id' to 'process-id', as that is what it is?
I actually thought that the path forward for multi-process debugging
would be to add the --process option.

> 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.

I'm afraid I don't understand the last sentence. Can you clarify?

- Volodya