Re: [RFC] -mi-level command

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

> 
> 
> > Bonjour
> > 
> > 	Maybe there is a better way to do this, most clients of GDB/MI
> > need a way to know the level to adjust the parsing or go around bugs in
> > previous(or current version).
> > 
> > 	One problem with the code below is that mi_version() is returning ..."3"
> 
> Should it also include the gdb version string?

It is already covered by:
	-gdb-version

> Should it indicate the range of supported MI versions?
> (what ever is useful).

I think what you are referring is a set command like

-mi-set-level "mi2"

In this case, I am only interested in knowing the mi protocol version.

For example the parsing of "-thread-list-ids" at level "mi1" is
completely different then "mi2" and "mi3".

"mi0" != "mi1" != "mi2" != "mi3"

In otherwords having "mi2" does not mean I can parse output
or use command of "mi1" level.

It is probably not possible to be backward compatible.
Backward compatible would imply a parser that was written for "mi0"
should work for "mi1" or "mi2" ...  It is currently not the case.
It is important for the folks using "GDB/MI" to know
the version when exchanging with gdb because of this, spawning
"gdb -i mi" does not say much.


> 
> 'gdb -i=mi2' should get you back to something that was released in 5.3. 
>   "mi3" won't become official until GDB 6 is released, however, for it 
> it return "2" would be wrong.
> 

Well the problem is that the function mi_version() is returning "3"
How can I, reliably, get the MI version beeing use?

> It will need documentation and a testcase.
> 

Agreed, will do, if the new command is accepted.

BTW: seems to have some confusion with "MI level" and "MI version"

Should the command name be :
-mi-level
or
-mi-version

??
> Andrew
> 
> There is a problem here though

8-) ok.