Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [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