Re: MI level command

[Andrew Cagney <cagney at gnu dot org>]

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

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

Andrew