Re: MI level command

["Alain Magloire" <alain@qnx.com>]

> 
> > Yellow
> > 
> > 
> > Scenario:  We want to know wich level of MI that we are currently working in.
> >   This can allow to adjust what MI command to use and how to parse them.
> > 
> > Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
> >   The version of  gdb
> >      gdb --version
> >   show different things in different distributions, sometimes it is a number based on date
> >   etc ...
> > 
> > So would a patch implementing
> > 
> >  -gdb-mi-level
> >  ^done,level=1
> > 
> > be a good thing ?
> 
> This needs to be resolved.
> 
> I think its become clear that clients are choosing to support multiple 
> debugger releases rather than certifying against a single debugger and 
> mi version.  This is contrary to the expectation that the clients would 
> tightly couple their front end to a specific GDB and MI version, and 
> consequently, when starting GDB, specify a specific MI version.
> 

Yes, some embedded platforms are still using old versions and for whatever
reasons and can not move the latest/greatest.  Frontends still need to cope
with this and detecting the version of MI will allow them to adjust.

> Given this, we need to change the way versioning is handled.
> 
> - we can't create a situtation where GDB is required to retain existing 
> [broken] behavior indefinitly
> 
> - we can certainly look for ways that let the client use both old and 
> newer GDB's - the clients then get to decide how much backward 
> incompatibility they wish to retain without imposing the burdon on GDB.
> 
> To that end:
> 
> -> we should probably implement significant command output (and more 
> importantly input) changes by adding a new command.  A missing new 
> command is easy to detect, just run it with no options.
> 
> -> minor output changes (new field for instance) do not need a new command
> 
> -> MI version changes tied to significant changes
> 

100% agreement, here 8-).

Thanks.