Re: MI non-stop interface details

[Vladimir Prus <vladimir@codesourcery.com>]

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