This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] -mi-level command
- From: "Alain Magloire" <alain at qnx dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Wed, 7 May 2003 16:28:38 -0400 (EDT)
- Subject: Re: [RFC] -mi-level command
>
>
> > 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.