MI non-stop interface details

[Pawel Piech]

Vladimir Prus wrote:
> On Thursday 01 May 2008 20:50:28 Pawel Piech wrote:
>       
>   
>>> In DSF-GDB there _is_ a central place where commands are sent, this is
>>> where the protocol state is adjusted using -thread-select.  However, the
>>> --thread option is being added to many but not all commands, so the same
>>> mechanism that adds the -thread-select could not be reused to add
>>> --thread option.  Instead each command which accepts --thread that would
>>> need to be adjusted to use the --thread, but only when in non-stop
>>> debugging mode.
>>>       
>>     
>>
>> This is not actually. The plan is for eery command will accept --thread.  
>> Those that don't have any use of it will ignore it. The only command,
>> at the moment, for which the meaning of --thread is not yet clear, and for
>> which the frontend might have to have custom decision logic, is --exec-continue.
>>
>> - Volodya
>>   
>>  That's helpful.  Unfortunately UI clients that want to have a wide user base still 
>>  need to worry about old GDB versions which do not support -thread, and that was my 
>>  first point in this thread.  As I've seen on this mailing list there are users out 
>>  there still on GDB 5.x.  I expect it will take several 
>>  years before support for GDB 6.8 and prior is not so important.    
>>     
>
> And where's the issue? On startup, issue -list-features. If you get error, this is old
> GDB. If the output of -list-features does not include "thread-option", this version of
> GDB does not support --thread (and don't not support non-stop, either). Then, you
> can make appropriate runtime decisions. It seems better to me to make such global
> decision right after starting GDB, rather than guessing things from output of *stopped,
> and other indirect mechanisms.
>
>   
> [Note that "thread-option" is not yet produced by -list-features, because the support
> for --thread is not yet in FSF tree]
>
> - Volodya
>   
I disagree.  I think it is more direct to place the logic of deciphering 
the meaning of the event with the code that handles that event.  If 
there are optional fields in the event, they can be interpreted if 
present and interpreted another way if not present, but the logic is 
very localized.
Using -list-features to determine what the protocol behavior is, forces 
the client to scatter logic about how to interpret events and use 
commands.  The code that launches and configures GDB is typically in a 
different component than the code that interprets events and sends 
individual commands.  In other words, the problem with using 
-list-features to determine the protocol behavior is that it makes it 
more difficult for the client to keep its code modular. 

(warning: soap box speach coming)
I have to admit though that history is on your side.  Through its many 
versions GDB has freely changed (or "cleaned up") the MI protocol in 
subtle ways without warning (e.g. adding quotes around the condition 
parameter in -break-condition).  This creates headaches for clients, and 
can ultimately make the client code difficult to maintain. A perfect 
example of this is the CDI-GDB Eclipse integration.  While it has other 
architectural issues, the myriad of workarounds for various GDB versions 
in it makes it difficult to know whether a change for latest GDB version 
won't break support for old GDB versions.  What I don't think GDB 
maintainers realize is that ultimately this policy does a lot of harm to 
GDB adoption and GDB's reputation in the larger community.  I would 
guess that most users of GDB have some kind of graphical interface and 
their quality is linked to perception of quality of GDB.   GDB/MI is a 
published protocol with many users, and I wish that this fact had more 
significance to its maintainers.

Cheers,
Pawel