Re: MI non-stop interface details

[Pawel Piech <pawel dot piech at windriver dot com>]

Vladimir Prus wrote:
> Again -- exec-continue resuming just one thread will be a change in behaviour.
> We can take two approaches:
>
> 1. The MI interface we've discussed for non-stop is essentially MI3 (and will
> be used both in all-stop and non-stop mode). We're in position to change anything
> we like, and are not bound by backward compatibility, or anything.
>
> 2. The MI interface for non-stop is MI2 + minimal set of changes. I think that
> Pawel's opposition to the --thread idea indicates that he prefers this approach.
> Then, we rather not change the behaviour of existing commands.
>
> There are not many high-level warts in MI2/non-stop/async, so I'm willing
> to go with (2).
>
> - Volodya
>   

First of all I really appreciate your effort to maintain backward 
compatibility.  I know that it can seriously complicate the effort to 
add new features but I believe this effort pays off in quicker and more 
reliable adoption by the users (IDEs).  However, there are two kinds of 
backward compatibility goals to consider:
1) Allowing old GDB clients to use the new, extended protocol.
2) Allow clients that use the extended protocol to easily work with old 
protocol versions.  And by "easily", I mean that the client should be 
able to not have "if(non-stop) { use command a } else { use command b}" 
kind of logic scattered throughout its implementation.

Goal 1) is a little more obvious and it is being satisfied by having an 
explicit all-stop/non-stop switch which has to be set in order to enable 
the new protocol extensions. Goal 2) is somewhat more complicated and 
difficult to achieve but I think it is possible with a few adjustments 
to the current proposal.  (Note that the second goal is actually not 
just about compatibility with older versions, it also has to do with 
using the latest version of GDB with targets that don't support.) 
non-stop mode.

As far as the protocol is concerned, I think the best way to think about 
the difference between non-stop and all-stop is that all-stop is a 
degenerate mode of non-stop where the all-stop mode has the limitation 
that resuming a single thread always has the side effect of resuming the 
entire process.  The first step in allowing the client to deal with this 
difference is to add a field to the state change events which indicate 
what context has actually changed state.  For this purpose I previously 
suggested adding a "container-ids" parameter to the *resumed and 
*stopped events.  In the extended protocol, this parameter would tell 
the client whether the whole process was resumed or just a single 
thread, and it should be present in either non-stop or all-stop mode.  
When working with older versions of GDB, this parameter would be absent, 
which would allow the client to deduce that the whole process was resumed.

The next problem to solve is the fact that non-stop needs an additional 
feature: explicitly resuming/stopping/stepping the entire process.  
That's right, if you think of all-stop as a degenerate mode, it's not 
controlling the individual threads that is new, but it is controlling of 
the entire process that needs to be added.  One way to add this feature 
is to extend the run control commands to take a special parameter, i.e. 
-all/--thread-id="all", etc.  The draw-back to this approach is that it 
would still require the client to have the "if (non-stop)..." kind of 
logic in its processing, because old versions of GDB would return an 
error if they saw this option.  But there is a way around this (which I 
proposed before but which I didn't receive any response about):  
Designate thread "1" as the default container thread.  I.e. sending 
"-exec-continue --thread-id="1"" would resume the entire process 
("-thread-select 1" followed by "-exec-continue") would do the same.  
All other logic dealing with threads, -thread-list-ids, -thread-info, 
etc could still work as it does today, it would just return threads 
starting with id of "2".  When working with old versions of GDB, thread 
1 is always present, and since old versions of GDB implement all-stop 
mode only, the resume-all button in the IDE would still work as expected.

I assume there must be implementation complications to this propsal, but 
as I've mentioned before, but I think it's worth considering as it would 
also allow GDB to easily extend the MI protocol to support multi-process 
debugging, where a new command:
"-list-container-ids" would return the thread-ids of processes, and 
"-list-thread-ids --thread-id="1"" would return threads within the given 
container.

-Pawel