* [RFC] -mi-level command
@ 2003-05-07 18:34 Alain Magloire
2003-05-07 19:40 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Alain Magloire @ 2003-05-07 18:34 UTC (permalink / raw)
To: gdb-patches
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"
I'll be happy to provide docs etc .. after.
8<---8<---------------------------------------
Index: mi-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
retrieving revision 1.12
diff -u -r1.12 mi-cmds.c
--- mi-cmds.c 4 May 2003 03:50:13 -0000 1.12
+++ mi-cmds.c 7 May 2003 18:24:34 -0000
@@ -96,6 +96,7 @@
{"kod-list", 0, 0},
{"kod-list-object-types", 0, 0},
{"kod-show", 0, 0},
+ {"mi-level", 0, 0, mi_cmd_mi_level},
{"overlay-auto", 0, 0},
{"overlay-list-mapping-state", 0, 0},
{"overlay-list-overlays", 0, 0},
Index: mi-cmds.h
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.h,v
retrieving revision 1.9
diff -u -r1.9 mi-cmds.h
--- mi-cmds.h 4 May 2003 03:50:13 -0000 1.9
+++ mi-cmds.h 7 May 2003 18:24:34 -0000
@@ -81,6 +81,7 @@
extern mi_cmd_args_ftype mi_cmd_exec_until;
extern mi_cmd_args_ftype mi_cmd_exec_interrupt;
extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_file;
+extern mi_cmd_argv_ftype mi_cmd_mi_level;
extern mi_cmd_argv_ftype mi_cmd_gdb_exit;
extern mi_cmd_argv_ftype mi_cmd_interpreter_exec;
extern mi_cmd_argv_ftype mi_cmd_stack_info_depth;
Index: mi-main.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-main.c,v
retrieving revision 1.43
diff -u -r1.43 mi-main.c
--- mi-main.c 5 May 2003 17:56:57 -0000 1.43
+++ mi-main.c 7 May 2003 18:24:34 -0000
@@ -109,6 +109,13 @@
formalized. */
enum mi_cmd_result
+mi_cmd_mi_level (char *command, char **argv, int argc)
+{
+ ui_out_field_int (uiout, "level", mi_version(uiout));
+ return MI_CMD_DONE;
+}
+
+enum mi_cmd_result
mi_cmd_gdb_exit (char *command, char **argv, int argc)
{
/* We have to print everything right here because we never return */
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] -mi-level command
2003-05-07 18:34 [RFC] -mi-level command Alain Magloire
@ 2003-05-07 19:40 ` Andrew Cagney
2003-05-07 20:28 ` Alain Magloire
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-05-07 19:40 UTC (permalink / raw)
To: Alain Magloire; +Cc: gdb-patches
> 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?
Should it indicate the range of supported MI versions?
(what ever is useful).
'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.
It will need documentation and a testcase.
Andrew
There is a problem here though
> I'll be happy to provide docs etc .. after.
> 8<---8<---------------------------------------
> Index: mi-cmds.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
> retrieving revision 1.12
> diff -u -r1.12 mi-cmds.c
> --- mi-cmds.c 4 May 2003 03:50:13 -0000 1.12
> +++ mi-cmds.c 7 May 2003 18:24:34 -0000
> @@ -96,6 +96,7 @@
> {"kod-list", 0, 0},
> {"kod-list-object-types", 0, 0},
> {"kod-show", 0, 0},
> + {"mi-level", 0, 0, mi_cmd_mi_level},
> {"overlay-auto", 0, 0},
> {"overlay-list-mapping-state", 0, 0},
> {"overlay-list-overlays", 0, 0},
> Index: mi-cmds.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/mi/mi-cmds.h,v
> retrieving revision 1.9
> diff -u -r1.9 mi-cmds.h
> --- mi-cmds.h 4 May 2003 03:50:13 -0000 1.9
> +++ mi-cmds.h 7 May 2003 18:24:34 -0000
> @@ -81,6 +81,7 @@
> extern mi_cmd_args_ftype mi_cmd_exec_until;
> extern mi_cmd_args_ftype mi_cmd_exec_interrupt;
> extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_file;
> +extern mi_cmd_argv_ftype mi_cmd_mi_level;
> extern mi_cmd_argv_ftype mi_cmd_gdb_exit;
> extern mi_cmd_argv_ftype mi_cmd_interpreter_exec;
> extern mi_cmd_argv_ftype mi_cmd_stack_info_depth;
> Index: mi-main.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/mi/mi-main.c,v
> retrieving revision 1.43
> diff -u -r1.43 mi-main.c
> --- mi-main.c 5 May 2003 17:56:57 -0000 1.43
> +++ mi-main.c 7 May 2003 18:24:34 -0000
> @@ -109,6 +109,13 @@
> formalized. */
>
> enum mi_cmd_result
> +mi_cmd_mi_level (char *command, char **argv, int argc)
> +{
> + ui_out_field_int (uiout, "level", mi_version(uiout));
Indentation, space before the lparen.
> + return MI_CMD_DONE;
> +}
> +
> +enum mi_cmd_result
> mi_cmd_gdb_exit (char *command, char **argv, int argc)
> {
> /* We have to print everything right here because we never return */
>
>
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] -mi-level command
2003-05-07 19:40 ` Andrew Cagney
@ 2003-05-07 20:28 ` Alain Magloire
2003-06-22 18:15 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Alain Magloire @ 2003-05-07 20:28 UTC (permalink / raw)
To: gdb-patches
>
>
> > 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] -mi-level command
2003-05-07 20:28 ` Alain Magloire
@ 2003-06-22 18:15 ` Andrew Cagney
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2003-06-22 18:15 UTC (permalink / raw)
To: Alain Magloire; +Cc: gdb-patches
>> Should it also include the gdb version string?
>
>
> It is already covered by:
> -gdb-version
Doh!
>> 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.
Ok.
>> '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?
Use a GDB from a released branch (hope I remember to do the next one
correctly). At that point -gdb-version should return something
meaningful, and -mi-version will be considered frozen.
The gdb on the mainline gets its mi version rolled as soon as something
incompatible gets changed. So while the last release reports "2", the
mainline reports the work-in-progress "3".
>> 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
Argh.
I suspect -mi-version is better. There are potential incompatibilities
between the diferent versions.
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-06-22 18:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-07 18:34 [RFC] -mi-level command Alain Magloire
2003-05-07 19:40 ` Andrew Cagney
2003-05-07 20:28 ` Alain Magloire
2003-06-22 18:15 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox