[patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 249 bytes --]

Hello,

The attached patch updates things so that "mi2" is the default MI 
syntax.  I need to add a mechanism so that the MI code can query the 
version but I'll post that separatly.

It modifies NEWS (comments?).
It updates the doco (ok?).

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 5664 bytes --]

Index: ChangeLog
2002-09-29  Andrew Cagney  <ac131313@redhat.com>

	* NEWS: Mention that MI syntax changed to "mi2" and that "mi0"
	syntax has been removed.

Index: doc/ChangeLog
2002-09-29  Andrew Cagney  <ac131313@redhat.com>

	* gdb.texinfo (Mode Options): Update --interpreter option.  "mi2"
	and "mi1" instead of "mi1" and "mi0".

Index: mi/ChangeLog
2002-09-29  Andrew Cagney  <ac131313@redhat.com>

	* mi-main.c (mi2_command_loop): New function.
	(mi0_command_loop): Delete function.
	(_initialize_mi_main): Recognize, and default to, "mi2".  Do not
	recognize "mi0".
	* mi-out.c (mi_table_begin): Remove mi0 code.
	(mi_table_body, mi_table_end): Ditto.
	(mi_table_header, mi_open, mi_close): Ditto.

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.93
diff -u -r1.93 NEWS
--- NEWS	21 Sep 2002 11:55:17 -0000	1.93
+++ NEWS	29 Sep 2002 18:08:05 -0000
@@ -3,6 +3,15 @@
 
 *** Changes since GDB 5.3:
 
+* Default MI syntax changed to "mi2".
+
+The default MI (machine interface) syntax, selected with the command
+line option "-i=mi", has been changed to "mi2".  The previous MI
+syntax can still be selected using "-i=mi1".
+
+Support for the original "mi0" syntax (included in GDB 5.0) has been
+removed.
+
 * REMOVED configurations and files
 
 V850EA ISA				
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.127
diff -u -r1.127 gdb.texinfo
--- doc/gdb.texinfo	25 Sep 2002 22:55:30 -0000	1.127
+++ doc/gdb.texinfo	29 Sep 2002 18:08:19 -0000
@@ -1127,10 +1127,10 @@
 program or device.  This option is meant to be set by programs which
 communicate with @value{GDBN} using it as a back end.
 
-@samp{--interpreter=mi} (or @samp{--interpreter=mi1}) causes
+@samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
 @value{GDBN} to use the @dfn{gdb/mi interface} (@pxref{GDB/MI, , The
 @sc{gdb/mi} Interface}). The older @sc{gdb/mi} interface, included in
-@value{GDBN} version 5.0 can be selected with @samp{--interpreter=mi0}.
+@value{GDBN} version 5.3 can be selected with @samp{--interpreter=mi1}.
 
 @item -write
 @cindex @code{--write}
Index: mi/mi-main.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-main.c,v
retrieving revision 1.31
diff -u -r1.31 mi-main.c
--- mi/mi-main.c	11 Sep 2002 21:49:04 -0000	1.31
+++ mi/mi-main.c	29 Sep 2002 18:08:23 -0000
@@ -1514,15 +1514,15 @@
 }
 
 static void
-mi0_command_loop (void)
+mi1_command_loop (void)
 {
-  mi_command_loop (0);
+  mi_command_loop (1);
 }
 
 static void
-mi1_command_loop (void)
+mi2_command_loop (void)
 {
-  mi_command_loop (1);
+  mi_command_loop (2);
 }
 
 static void
@@ -1547,11 +1547,11 @@
     return;
 
   /* If we're _the_ interpreter, take control. */
-  if (strcmp (interpreter_p, "mi0") == 0)
-    command_loop_hook = mi0_command_loop;
-  else if (strcmp (interpreter_p, "mi") == 0
-	   || strcmp (interpreter_p, "mi1") == 0)
+  if (strcmp (interpreter_p, "mi1") == 0)
     command_loop_hook = mi1_command_loop;
+  else if (strcmp (interpreter_p, "mi") == 0
+	   || strcmp (interpreter_p, "mi2") == 0)
+    command_loop_hook = mi2_command_loop;
   else
     return;
 
Index: mi/mi-out.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-out.c,v
retrieving revision 1.23
diff -u -r1.23 mi-out.c
--- mi/mi-out.c	19 Mar 2002 02:51:08 -0000	1.23
+++ mi/mi-out.c	29 Sep 2002 18:08:23 -0000
@@ -109,14 +109,6 @@
 {
   struct ui_out_data *data = ui_out_data (uiout);
   mi_open (uiout, tblid, ui_out_type_tuple);
-  if (data->mi_version == 0)
-    {
-      if (nr_rows == 0)
-	data->suppress_output = 1;
-      else
-	mi_open (uiout, "hdr", ui_out_type_list);
-      return;
-    }
   mi_field_int (uiout, -1/*fldno*/, -1/*width*/, -1/*alin*/,
 		"nr_rows", nr_rows);
   mi_field_int (uiout, -1/*fldno*/, -1/*width*/, -1/*alin*/,
@@ -134,8 +126,6 @@
     return;
   /* close the table header line if there were any headers */
   mi_close (uiout, ui_out_type_list);
-  if (data->mi_version == 0)
-    return;
   mi_open (uiout, "body", ui_out_type_list);
 }
 
@@ -146,11 +136,6 @@
 {
   struct ui_out_data *data = ui_out_data (uiout);
   data->suppress_output = 0;
-  if (data->mi_version == 0)
-    {
-      mi_close (uiout, ui_out_type_tuple);
-      return;
-    }
   mi_close (uiout, ui_out_type_list); /* body */
   mi_close (uiout, ui_out_type_tuple);
 }
@@ -165,11 +150,6 @@
   struct ui_out_data *data = ui_out_data (uiout);
   if (data->suppress_output)
     return;
-  if (data->mi_version == 0)
-    {
-      mi_field_string (uiout, 0, width, alignment, 0, colhdr);
-      return;
-    }
   mi_open (uiout, NULL, ui_out_type_tuple);
   mi_field_int (uiout, 0, 0, 0, "width", width);
   mi_field_int (uiout, 0, 0, 0, "alignment", alignment);
@@ -361,10 +341,7 @@
       fputc_unfiltered ('{', data->buffer);
       break;
     case ui_out_type_list:
-      if (data->mi_version == 0)
-	fputc_unfiltered ('{', data->buffer);
-      else
-	fputc_unfiltered ('[', data->buffer);
+      fputc_unfiltered ('[', data->buffer);
       break;
     default:
       internal_error (__FILE__, __LINE__, "bad switch");
@@ -382,10 +359,7 @@
       fputc_unfiltered ('}', data->buffer);
       break;
     case ui_out_type_list:
-      if (data->mi_version == 0)
-	fputc_unfiltered ('}', data->buffer);
-      else
-	fputc_unfiltered (']', data->buffer);
+      fputc_unfiltered (']', data->buffer);
       break;
     default:
       internal_error (__FILE__, __LINE__, "bad switch");

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Daniel Jacobowitz]

On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote:
> Hello,
> 
> The attached patch updates things so that "mi2" is the default MI 
> syntax.  I need to add a mechanism so that the MI code can query the 
> version but I'll post that separatly.
> 
> It modifies NEWS (comments?).
> It updates the doco (ok?).
> 
> Andrew

It seems to me that this is going about everything backwards.

There isn't an mi2 yet, is there?  Only mi1 and some incompatible,
proposed changes.  Why are we making the default mi2 before we figure
out what mi2 is?

Not necessarily bad, but definitely unintuitive.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

> On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote:
> 
>> Hello,
>> 
>> The attached patch updates things so that "mi2" is the default MI 
>> syntax.  I need to add a mechanism so that the MI code can query the 
>> version but I'll post that separatly.
>> 
>> It modifies NEWS (comments?).
>> It updates the doco (ok?).
>> 
>> Andrew
> 
> 
> It seems to me that this is going about everything backwards.
> 
> There isn't an mi2 yet, is there?

Actually, I think "mi2" changes have been sneeking through for a while. 
  The attached, for instance, modifies [fixes] a commands output in a 
way that isn't backward compatible.

enjoy,
Andrew


[-- Attachment #2: mailbox-message://ac131313@movemail/fsf/gdb/patches#23215 --]
[-- Type: message/rfc822, Size: 45935 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 761 bytes --]

The attached patch changes the output format of the mi -var-update command to
use a list for "changelist" rather than a single tuple.

Approved?

-- Jeff J.

2002-09-27  Jeff Johnston  <jjohnstn@redhat.com>
	
	* mi/mi-cmd-var.c (mi_cmd_var_update): Fix for PR gdb/672.  Output
	list begin and end for "changelist" rather than tuple begin/end.
	(varobj_update_one): Add tuple begin and end for varobj update output.
	* testsuite/gdb.mi/mi-var-block.exp: Change expected output from -var-update
	command to expect list format for "changelist".
	* testsuite/gdb.mi/mi-var-cmd.exp: Ditto.
	* testsuite/gdb.mi/mi-var-child: Ditto.
	* testsuite/gdb.mi/mi0-var-block.exp: Ditto.
	* testsuite/gdb.mi/mi0-var-cmd.exp: Ditto.
	* testsuite/gdb.mi/mi0-var-child.exp: Ditto.

[-- Attachment #2.1.2: 672.patch --]
[-- Type: text/plain, Size: 42195 bytes --]

Index: mi/mi-cmd-var.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-var.c,v
retrieving revision 1.12
diff -u -r1.12 mi-cmd-var.c
--- mi/mi-cmd-var.c	30 Jul 2002 13:45:15 -0000	1.12
+++ mi/mi-cmd-var.c	27 Sep 2002 22:14:26 -0000
@@ -419,10 +419,10 @@
   if ((*name == '*') && (*(name + 1) == '\0'))
     {
       nv = varobj_list (&rootlist);
-      ui_out_tuple_begin (uiout, "changelist");
+      ui_out_list_begin (uiout, "changelist");
       if (nv <= 0)
 	{
-	  ui_out_tuple_end (uiout);
+	  ui_out_list_end (uiout);
 	  return MI_CMD_DONE;
 	}
       cr = rootlist;
@@ -432,7 +432,7 @@
 	  cr++;
 	}
       xfree (rootlist);
-      ui_out_tuple_end (uiout);
+      ui_out_list_end (uiout);
     }
   else
     {
@@ -441,9 +441,9 @@
       if (var == NULL)
 	error ("mi_cmd_var_update: Variable object not found");
 
-      ui_out_tuple_begin (uiout, "changelist");
+      ui_out_list_begin (uiout, "changelist");
       varobj_update_one (var);
-      ui_out_tuple_end (uiout);
+      ui_out_list_end (uiout);
     }
     return MI_CMD_DONE;
 }
@@ -469,17 +469,21 @@
     return 1;
   else if (nc == -1)
     {
+      ui_out_tuple_begin (uiout, NULL);
       ui_out_field_string (uiout, "name", varobj_get_objname(var));
       ui_out_field_string (uiout, "in_scope", "false");
+      ui_out_tuple_end (uiout);
       return -1;
     }
   else if (nc == -2)
     {
+      ui_out_tuple_begin (uiout, NULL);
       ui_out_field_string (uiout, "name", varobj_get_objname (var));
       ui_out_field_string (uiout, "in_scope", "true");
       ui_out_field_string (uiout, "new_type", varobj_get_type(var));
       ui_out_field_int (uiout, "new_num_children", 
 			   varobj_get_num_children(var));
+      ui_out_tuple_end (uiout);
     }
   else
     {
@@ -487,9 +491,11 @@
       cc = changelist;
       while (*cc != NULL)
 	{
+	  ui_out_tuple_begin (uiout, NULL);
 	  ui_out_field_string (uiout, "name", varobj_get_objname (*cc));
 	  ui_out_field_string (uiout, "in_scope", "true");
 	  ui_out_field_string (uiout, "type_changed", "false");
+	  ui_out_tuple_end (uiout);
 	  cc++;
 	}
       xfree (changelist);
Index: testsuite/gdb.mi/mi-var-block.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-var-block.exp,v
retrieving revision 1.7
diff -u -r1.7 mi-var-block.exp
--- testsuite/gdb.mi/mi-var-block.exp	17 Sep 2002 20:30:24 -0000	1.7
+++ testsuite/gdb.mi/mi-var-block.exp	27 Sep 2002 22:14:27 -0000
@@ -104,7 +104,7 @@
 # Test: c_variable-3.4
 # Desc: check foo, cb changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"foo\",in_scope=\"true\",type_changed=\"false\",name=\"cb\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"foo\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"cb\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: cb foo changed"
 
 # step to "foo = 321;"
@@ -155,7 +155,7 @@
 clear_xfail *-*-*
 
 mi_gdb_test "-var-update foo" \
-	"\\^done,changelist=\{\}" \
+	"\\^done,changelist=\\\[\\\]" \
 	"update foo: did not change"
 
 mi_gdb_test "-var-delete inner_foo" \
@@ -193,7 +193,7 @@
 # Desc: check that only cb is in scope (known gdb problem)
 setup_xfail *-*-*
 mi_gdb_test "-var-update foo2" \
-	"\\^done,changelist=\{FIXME\}" \
+	"\\^done,changelist=\\\[FIXME\\\]" \
 	"update foo2 should be out of scope: KNOWN PROBLEM"
 clear_xfail *-*-*
 setup_xfail *-*-*
@@ -202,7 +202,7 @@
 	"update foo should be out of scope: KNOWN PROBLEM"
 clear_xfail *-*-*
 mi_gdb_test "-var-update cb" \
-	"\\^done,changelist=\{\}" \
+	"\\^done,changelist=\\\[\\\]" \
 	"update cb"
 
 # Test: c_variable-3.10
Index: testsuite/gdb.mi/mi-var-child.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-var-child.exp,v
retrieving revision 1.11
diff -u -r1.11 mi-var-child.exp
--- testsuite/gdb.mi/mi-var-child.exp	13 Sep 2002 21:29:42 -0000	1.11
+++ testsuite/gdb.mi/mi-var-child.exp	27 Sep 2002 22:14:27 -0000
@@ -750,7 +750,7 @@
 # Test: c_variable-5.1
 # Desc: check that nothing changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{\}" \
+	"\\^done,changelist=\\\[\\\]" \
 	"update all vars. None changed"
 
 # Step over "struct_declarations.integer = 123;"
@@ -760,7 +760,7 @@
 # Test: c_variable-5.2
 # Desc: check that integer changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.integer\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"struct_declarations.integer\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars struct_declarations.integer"
 
 # Step over:
@@ -773,7 +773,7 @@
 # Test: c_variable-5.3
 # Desc: check that char_ptr changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"struct_declarations.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars struct_declarations.char_ptr"
 
 # Step over "struct_declarations.int_ptr_ptr = &foo;"
@@ -783,7 +783,7 @@
 # Test: c_variable-5.4
 # Desc: check that int_ptr_ptr and children changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr.\\*\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr.\\*\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr.\\*\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr.\\*\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars int_ptr_ptr and children changed"
 
 # Step over "weird->long_array[0] = 1234;"
@@ -793,7 +793,7 @@
 # Test: c_variable-5.5
 # Desc: check that long_array[0] changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.long_array.0\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"struct_declarations.long_array.0\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars struct_declarations.long_array.0 changed"
 
 # Step over "struct_declarations.long_array[1] = 2345;"
@@ -803,7 +803,7 @@
 # Test: c_variable-5.6
 # Desc: check that long_array[1] changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.long_array.1\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"struct_declarations.long_array.1\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars struct_declarations.long_array.1 changed"
 
 # Step over "weird->long_array[2] = 3456;"
@@ -813,7 +813,7 @@
 # Test: c_variable-5.7
 # Desc: check that long_array[2] changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.long_array.2\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"struct_declarations.long_array.2\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars struct_declarations.long_array.2 changed"
 
 # Step over:
@@ -830,7 +830,7 @@
 # Test: c_variable-5.8
 # Desc: check that long_array[3-9] changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.long_array.3\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.4\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.5\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.6\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.7\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.8\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.9\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"struct_declarations.long_array.3\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.4\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.5\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.6\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.7\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.8\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.9\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars struct_declarations.long_array.3-9 changed"
 
 
@@ -841,7 +841,7 @@
 # Test: c_variable-5.9
 # Desc: check that func_ptr changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.func_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"struct_declarations.func_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars struct_declarations.func_ptr changed"
 
 # Delete all variables
@@ -1133,7 +1133,7 @@
 # Test: c_variable-5.47
 # Desc: check that psnp->char_ptr (and [0].char_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr.\\*\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr.\\*\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars psnp->char_ptr (and 0.char_ptr) changed"
 
 #  Step over "snp1.char_ptr = &c3;"
@@ -1143,7 +1143,7 @@
 # Test: c_variable-5.48
 # Desc: check that psnp->next->char_ptr (and [1].char_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.next.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr.\\*\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr.\\*\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars psnp->next->char_ptr (and 1.char_ptr) changed"
 
 
@@ -1154,7 +1154,7 @@
 # Test: c_variable-5.49
 # Desc: check that psnp->next->next->char_ptr (and [2].char_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.next.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.next.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars psnp->next->next->char_ptr (and 2.char_ptr) changed"
 
 
@@ -1165,7 +1165,7 @@
 # Test: c_variable-5.50
 # Desc: check that psnp->long_ptr (and [0].long_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr.\\*\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr.\\*\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars psnp->long_ptr (and 0.long_ptr) changed"
 
 
@@ -1178,7 +1178,7 @@
 # Why does this have a FIXME?
 setup_xfail *-*-*
 mi_gdb_test "-var-update *" \
-	"FIXME\\^done,changelist=\{name=\"psnp->ptrs.0.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"FIXME\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars psnp->next->long_ptr (and 1.long_ptr) changed"
 clear_xfail *-*-*
 
@@ -1193,7 +1193,7 @@
 # Test: c_variable-5.52
 # Desc: check that psnp->next->next->long_ptr (and [2].long_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.next.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.next.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars psnp->next->next->long_ptr (and 2.long_ptr) changed"
 
 
Index: testsuite/gdb.mi/mi-var-cmd.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-var-cmd.exp,v
retrieving revision 1.12
diff -u -r1.12 mi-var-cmd.exp
--- testsuite/gdb.mi/mi-var-cmd.exp	17 Sep 2002 20:45:28 -0000	1.12
+++ testsuite/gdb.mi/mi-var-cmd.exp	27 Sep 2002 22:14:27 -0000
@@ -176,7 +176,7 @@
 # Test: c_variable-2.1
 # Desc: check whether values changed at do_block_tests
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{\}" \
+	"\\^done,changelist=\\\[\\\]" \
 	"update all vars"
 
 # Step over "linteger = 1234;"
@@ -185,7 +185,7 @@
 # Test: c_variable-2.2
 # Desc: check whether only linteger changed values
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: linteger changed"
 
 # Step over "lpinteger = &linteger;"
@@ -194,7 +194,7 @@
 # Test: c_variable-2.3
 # Desc: check whether only lpinteger changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: lpinteger changed"
 
 # Step over "lcharacter = 'a';"
@@ -203,7 +203,7 @@
 # Test: c_variable-2.4
 # Desc: check whether only lcharacter changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: lcharacter changed"
 
 # Step over "lpcharacter = &lcharacter;"
@@ -212,7 +212,7 @@
 # Test: c_variable-2.5
 # Desc: check whether only lpcharacter changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lpcharacter\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"lpcharacter\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: lpcharacter changed"
 
 
@@ -234,7 +234,7 @@
 # Desc: check whether llong, lplong, lfloat, lpfloat, ldouble, lpdouble, lsimple.integer,
 #       lsimple.unsigned_character lsimple.integer lsimple.character changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\",name=\"lpdouble\",in_scope=\"true\",type_changed=\"false\",name=\"ldouble\",in_scope=\"true\",type_changed=\"false\",name=\"lpfloat\",in_scope=\"true\",type_changed=\"false\",name=\"lfloat\",in_scope=\"true\",type_changed=\"false\",name=\"lplong\",in_scope=\"true\",type_changed=\"false\",name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpdouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"ldouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lplong\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: many changed"
 
 # Step over:
@@ -249,7 +249,7 @@
 # Test: c_variable-2.7
 # Desc: check whether (lsimple.signed_character, lsimple.char_ptr) lpsimple, func changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"func\",in_scope=\"true\",type_changed=\"false\",name=\"lpsimple\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"func\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpsimple\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: func and lpsimple changed"
 
 # Step over
@@ -271,7 +271,7 @@
 # Note: this test also checks that lpsimple->integer and lsimple.integer have
 #       changed (they are the same)
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\",name=\"ldouble\",in_scope=\"true\",type_changed=\"false\",name=\"lfloat\",in_scope=\"true\",type_changed=\"false\",name=\"llong\",in_scope=\"true\",type_changed=\"false\",name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\",name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"ldouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: func and lpsimple changed"
 
 
@@ -421,7 +421,7 @@
 # Test: c_variable-2.13
 # Desc: change subroutine1 local i
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"i\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"i\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: i changed"
 
 mi_step_to "subroutine1" "\{name=\"i\",value=\".*\"\},\{name=\"l\",value=\".*\"\}" \
@@ -430,7 +430,7 @@
 # Test: c_variable-2.14
 # Desc: change do_locals_tests local llong
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
 	"update all vars: llong changed"
 
 mi_next_to "do_locals_tests" ""	"var-cmd.c" "136" "next out of subroutine1"
@@ -438,7 +438,7 @@
 # Test: c_variable-2.15
 # Desc: check for out of scope subroutine1 locals
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"l\",in_scope=\"false\",name=\"i\",in_scope=\"false\"\}" \
+	"\\^done,changelist=\\\[\{name=\"l\",in_scope=\"false\"\},\{name=\"i\",in_scope=\"false\"\}\\\]" \
 	"update all vars: all now out of scope"
 
 # Done with locals/globals tests. Erase all variables
@@ -538,15 +538,15 @@
 mi_continue_to {.*} incr_a {.*} {.*var-cmd.c} {.*} {stop in incr_a}
 
 mi_gdb_test "-var-update selected_a" \
-  {\^done,changelist=\{name="selected_a",in_scope="true",new_type="char",new_num_children="0"\}} \
-  "update selected_a in incr_a"
+	"\\^done,changelist=\\\[\{name=\"selected_a\",in_scope=\"true\",new_type=\"char\",new_num_children=\"0\"\}\\\]" \
+	"update selected_a in incr_a"
 
 mi_next "step a line in incr_a"
 mi_next "return from incr_a to do_special_tests"
 
 mi_gdb_test "-var-update selected_a" \
-  {\^done,changelist=\{name="selected_a",in_scope="true",new_type="int",new_num_children="0"\}} \
-  "update selected_a in do_special_tests"
+	"\\^done,changelist=\\\[\{name=\"selected_a\",in_scope=\"true\",new_type=\"int\",new_num_children=\"0\"\}\\\]" \
+	"update selected_a in do_special_tests"
 
 mi_gdb_exit
 return 0
Index: testsuite/gdb.mi/mi0-var-block.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi0-var-block.exp,v
retrieving revision 1.4
diff -u -r1.4 mi0-var-block.exp
--- testsuite/gdb.mi/mi0-var-block.exp	19 Aug 2001 01:23:43 -0000	1.4
+++ testsuite/gdb.mi/mi0-var-block.exp	27 Sep 2002 22:14:27 -0000
@@ -104,7 +104,7 @@
 # Test: c_variable-3.4
 # Desc: check foo, cb changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"foo\",in_scope=\"true\",type_changed=\"false\",name=\"cb\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"foo\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"cb\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: cb foo changed"
 
 # step to "foo = 321;"
Index: testsuite/gdb.mi/mi0-var-child.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi0-var-child.exp,v
retrieving revision 1.7
diff -u -r1.7 mi0-var-child.exp
--- testsuite/gdb.mi/mi0-var-child.exp	17 Sep 2002 20:30:24 -0000	1.7
+++ testsuite/gdb.mi/mi0-var-child.exp	27 Sep 2002 22:14:27 -0000
@@ -787,7 +787,7 @@
 # Test: c_variable-5.2
 # Desc: check that integer changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.integer\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"struct_declarations.integer\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars struct_declarations.integer"
 
 # Step over:
@@ -808,7 +808,7 @@
 # Test: c_variable-5.3
 # Desc: check that char_ptr changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"struct_declarations.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars struct_declarations.char_ptr"
 
 # Step over "struct_declarations.int_ptr_ptr = &foo;"
@@ -825,7 +825,7 @@
 # Test: c_variable-5.4
 # Desc: check that int_ptr_ptr and children changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr.\\*\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr.\\*\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr.\\*\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr.\\*\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars int_ptr_ptr and children changed"
 
 # Step over "weird->long_array[0] = 1234;"
@@ -842,7 +842,7 @@
 # Test: c_variable-5.5
 # Desc: check that long_array[0] changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.long_array.0\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"struct_declarations.long_array.0\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars struct_declarations.long_array.0 changed"
 
 # Step over "struct_declarations.long_array[1] = 2345;"
@@ -859,7 +859,7 @@
 # Test: c_variable-5.6
 # Desc: check that long_array[1] changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.long_array.1\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"struct_declarations.long_array.1\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars struct_declarations.long_array.1 changed"
 
 # Step over "weird->long_array[2] = 3456;"
@@ -876,7 +876,7 @@
 # Test: c_variable-5.7
 # Desc: check that long_array[2] changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.long_array.2\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"struct_declarations.long_array.2\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars struct_declarations.long_array.2 changed"
 
 # Step over:
@@ -900,7 +900,7 @@
 # Test: c_variable-5.8
 # Desc: check that long_array[3-9] changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.long_array.3\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.4\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.5\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.6\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.7\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.8\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.9\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"struct_declarations.long_array.3\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.4\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.5\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.6\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.7\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.8\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.9\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars struct_declarations.long_array.3-9 changed"
 
 
@@ -918,7 +918,7 @@
 # Test: c_variable-5.9
 # Desc: check that func_ptr changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"struct_declarations.func_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"struct_declarations.func_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars struct_declarations.func_ptr changed"
 
 # Delete all variables
@@ -1224,7 +1224,7 @@
 # Test: c_variable-5.47
 # Desc: check that psnp->char_ptr (and [0].char_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr.\\*\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"psnp->ptrs.0.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr.\\*\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars psnp->char_ptr (and 0.char_ptr) changed"
 
 #  Step over "snp1.char_ptr = &c3;"
@@ -1242,7 +1242,7 @@
 # Test: c_variable-5.48
 # Desc: check that psnp->next->char_ptr (and [1].char_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.next.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr.\\*\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"psnp->ptrs.0.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr.\\*\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars psnp->next->char_ptr (and 1.char_ptr) changed"
 
 
@@ -1261,7 +1261,7 @@
 # Test: c_variable-5.49
 # Desc: check that psnp->next->next->char_ptr (and [2].char_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.next.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"psnp->ptrs.0.next.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars psnp->next->next->char_ptr (and 2.char_ptr) changed"
 
 
@@ -1279,7 +1279,7 @@
 # Test: c_variable-5.50
 # Desc: check that psnp->long_ptr (and [0].long_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr.\\*\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"psnp->ptrs.0.long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr.\\*\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars psnp->long_ptr (and 0.long_ptr) changed"
 
 
@@ -1300,7 +1300,7 @@
 # Why does this have a FIXME?
 setup_xfail *-*-*
 mi_gdb_test "-var-update *" \
-	"FIXME\\^done,changelist=\{name=\"psnp->ptrs.0.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"FIXME\\^done,changelist=\{\{name=\"psnp->ptrs.0.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars psnp->next->long_ptr (and 1.long_ptr) changed"
 clear_xfail *-*-*
 
@@ -1323,7 +1323,7 @@
 # Test: c_variable-5.52
 # Desc: check that psnp->next->next->long_ptr (and [2].long_ptr) changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"psnp->ptrs.0.next.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"psnp->ptrs.0.next.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars psnp->next->next->long_ptr (and 2.long_ptr) changed"
 
 
Index: testsuite/gdb.mi/mi0-var-cmd.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi0-var-cmd.exp,v
retrieving revision 1.9
diff -u -r1.9 mi0-var-cmd.exp
--- testsuite/gdb.mi/mi0-var-cmd.exp	17 Sep 2002 20:30:24 -0000	1.9
+++ testsuite/gdb.mi/mi0-var-cmd.exp	27 Sep 2002 22:14:27 -0000
@@ -185,7 +185,7 @@
 # Test: c_variable-2.2
 # Desc: check whether only linteger changed values
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: linteger changed"
 
 # Step over "lpinteger = &linteger;"
@@ -194,7 +194,7 @@
 # Test: c_variable-2.3
 # Desc: check whether only lpinteger changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: lpinteger changed"
 
 # Step over "lcharacter = 'a';"
@@ -203,7 +203,7 @@
 # Test: c_variable-2.4
 # Desc: check whether only lcharacter changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: lcharacter changed"
 
 # Step over "lpcharacter = &lcharacter;"
@@ -212,7 +212,7 @@
 # Test: c_variable-2.5
 # Desc: check whether only lpcharacter changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lpcharacter\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"lpcharacter\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: lpcharacter changed"
 
 
@@ -234,7 +234,7 @@
 # Desc: check whether llong, lplong, lfloat, lpfloat, ldouble, lpdouble, lsimple.integer,
 #       lsimple.unsigned_character lsimple.integer lsimple.character changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\",name=\"lpdouble\",in_scope=\"true\",type_changed=\"false\",name=\"ldouble\",in_scope=\"true\",type_changed=\"false\",name=\"lpfloat\",in_scope=\"true\",type_changed=\"false\",name=\"lfloat\",in_scope=\"true\",type_changed=\"false\",name=\"lplong\",in_scope=\"true\",type_changed=\"false\",name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpdouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"ldouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lplong\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: many changed"
 
 # Step over:
@@ -249,7 +249,7 @@
 # Test: c_variable-2.7
 # Desc: check whether (lsimple.signed_character, lsimple.char_ptr) lpsimple, func changed
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"func\",in_scope=\"true\",type_changed=\"false\",name=\"lpsimple\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"func\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpsimple\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: func and lpsimple changed"
 
 # Step over
@@ -271,7 +271,7 @@
 # Note: this test also checks that lpsimple->integer and lsimple.integer have
 #       changed (they are the same)
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\",name=\"ldouble\",in_scope=\"true\",type_changed=\"false\",name=\"lfloat\",in_scope=\"true\",type_changed=\"false\",name=\"llong\",in_scope=\"true\",type_changed=\"false\",name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\",name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"ldouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: func and lpsimple changed"
 
 
@@ -421,7 +421,7 @@
 # Test: c_variable-2.13
 # Desc: change subroutine1 local i
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"i\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"i\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: i changed"
 
 mi0_step_to "subroutine1" "\{name=\"i\",value=\".*\"\},\{name=\"l\",value=\".*\"\}" \
@@ -430,7 +430,7 @@
 # Test: c_variable-2.14
 # Desc: change do_locals_tests local llong
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}\}" \
 	"update all vars: llong changed"
 
 mi0_next_to "do_locals_tests" "" "var-cmd.c" "136" "next out of subroutine1"
@@ -438,7 +438,7 @@
 # Test: c_variable-2.15
 # Desc: check for out of scope subroutine1 locals
 mi_gdb_test "-var-update *" \
-	"\\^done,changelist=\{name=\"l\",in_scope=\"false\",name=\"i\",in_scope=\"false\"\}" \
+	"\\^done,changelist=\{\{name=\"l\",in_scope=\"false\"\},\{name=\"i\",in_scope=\"false\"\}\}" \
 	"update all vars: all now out of scope"
 
 # Done with locals/globals tests. Erase all variables

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Daniel Jacobowitz]

On Sun, Sep 29, 2002 at 04:19:11PM -0400, Andrew Cagney wrote:
> >On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>The attached patch updates things so that "mi2" is the default MI 
> >>syntax.  I need to add a mechanism so that the MI code can query the 
> >>version but I'll post that separatly.
> >>
> >>It modifies NEWS (comments?).
> >>It updates the doco (ok?).
> >>
> >>Andrew
> >
> >
> >It seems to me that this is going about everything backwards.
> >
> >There isn't an mi2 yet, is there?
> 
> Actually, I think "mi2" changes have been sneeking through for a while. 
>  The attached, for instance, modifies [fixes] a commands output in a 
> way that isn't backward compatible.

Are you planning to revert mi1 then?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

> On Sun, Sep 29, 2002 at 04:19:11PM -0400, Andrew Cagney wrote:
> 
>> >On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote:
>> >
> 
>> >>Hello,
>> >>
>> >>The attached patch updates things so that "mi2" is the default MI 
>> >>syntax.  I need to add a mechanism so that the MI code can query the 
>> >>version but I'll post that separatly.
>> >>
>> >>It modifies NEWS (comments?).
>> >>It updates the doco (ok?).
>> >>
>> >>Andrew
> 
>> >
>> >
>> >It seems to me that this is going about everything backwards.
>> >
>> >There isn't an mi2 yet, is there?
> 
>> 
>> Actually, I think "mi2" changes have been sneeking through for a while. 
>>  The attached, for instance, modifies [fixes] a commands output in a 
>> way that isn't backward compatible.
> 
> 
> Are you planning to revert mi1 then?

Que?

Andrew

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Daniel Jacobowitz]

On Sun, Sep 29, 2002 at 05:46:06PM -0400, Andrew Cagney wrote:
> >On Sun, Sep 29, 2002 at 04:19:11PM -0400, Andrew Cagney wrote:
> >
> >>>On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote:
> >>>
> >
> >>>>Hello,
> >>>>
> >>>>The attached patch updates things so that "mi2" is the default MI 
> >>>>syntax.  I need to add a mechanism so that the MI code can query the 
> >>>>version but I'll post that separatly.
> >>>>
> >>>>It modifies NEWS (comments?).
> >>>>It updates the doco (ok?).
> >>>>
> >>>>Andrew
> >
> >>>
> >>>
> >>>It seems to me that this is going about everything backwards.
> >>>
> >>>There isn't an mi2 yet, is there?
> >
> >>
> >>Actually, I think "mi2" changes have been sneeking through for a while. 
> >> The attached, for instance, modifies [fixes] a commands output in a 
> >>way that isn't backward compatible.
> >
> >
> >Are you planning to revert mi1 then?
> 
> Que?

"mi2" changes have been sneaking in.  Are you planning to revert them -
create an "mi1" which matches what mi1 actually was.

Otherwise, where is the line drawn to mark the interface version as
final?  It seems to me that the default shouldn't be evolving, that
-i=mi should default to a fixed point until the next version is
running.

Maybe I'm wrong though.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Eli Zaretskii]

On Sun, 29 Sep 2002, Andrew Cagney wrote:

> It modifies NEWS (comments?).

Fine with me.

> It updates the doco (ok?).

Yes, but perhaps the manual should also say that mi0 is no longer 
supported.

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

>> >
>> >Are you planning to revert mi1 then?
> 
>> 
>> Que?
> 
> 
> "mi2" changes have been sneaking in.  Are you planning to revert them -
> create an "mi1" which matches what mi1 actually was.

It's a bit late for that.  Someone should audit the changes made so far 
and identify which caused syntax changes and update accordingly.  Fixes 
could, perhaphs be pushed into 5.3 (but I don't have the time).

> Otherwise, where is the line drawn to mark the interface version as
> final?  It seems to me that the default shouldn't be evolving, that
> -i=mi should default to a fixed point until the next version is
> running.

I think a line is drawn when each release is made.  I'd expect an MI 
client to explicitly specify -i=miN (where N was formally released) 
rather than trust -i=mi.

However, should the HEAD hold off on recognizing -i=mi2 until the next 
branch is cut?  On the HEAD, -i=mi evolves by definition.  However, 
-i=mi2 is evolving as well :-(

Andrew

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Daniel Jacobowitz]

On Mon, Sep 30, 2002 at 11:03:55AM -0400, Andrew Cagney wrote:
> 
> >>>
> >>>Are you planning to revert mi1 then?
> >
> >>
> >>Que?
> >
> >
> >"mi2" changes have been sneaking in.  Are you planning to revert them -
> >create an "mi1" which matches what mi1 actually was.
> 
> It's a bit late for that.  Someone should audit the changes made so far 
> and identify which caused syntax changes and update accordingly.  Fixes 
> could, perhaphs be pushed into 5.3 (but I don't have the time).
> 
> >Otherwise, where is the line drawn to mark the interface version as
> >final?  It seems to me that the default shouldn't be evolving, that
> >-i=mi should default to a fixed point until the next version is
> >running.
> 
> I think a line is drawn when each release is made.  I'd expect an MI 
> client to explicitly specify -i=miN (where N was formally released) 
> rather than trust -i=mi.
> 
> However, should the HEAD hold off on recognizing -i=mi2 until the next 
> branch is cut?  On the HEAD, -i=mi evolves by definition.  However, 
> -i=mi2 is evolving as well :-(

That'd be best I think.  I think that -i=mi2 specifies a fixed standard
and we don't have one yet; so how about -i=mi being different from
-i=mi1, but not adding -i=mi2 until we're ready to fix the interface?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

>> However, should the HEAD hold off on recognizing -i=mi2 until the next 
>> branch is cut?  On the HEAD, -i=mi evolves by definition.  However, 
>> -i=mi2 is evolving as well :-(
> 
> 
> That'd be best I think.  I think that -i=mi2 specifies a fixed standard
> and we don't have one yet; so how about -i=mi being different from
> -i=mi1, but not adding -i=mi2 until we're ready to fix the interface?

I just looked, and I take the idea back.  It means updating NEWS, DOC 
and testsuite twice - just after the branch (to start the new interface) 
and just before a branch (to freeze the new interface).

I think its going to be easier to get it all done once just after the 
branch.  If someone reports a bug against a YYYYMMDD version of GDB then 
it's pretty clear that they are not using a released GDB.

Andrew

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

> On Sun, 29 Sep 2002, Andrew Cagney wrote:
> 
> 
>> It modifies NEWS (comments?).
> 
> 
> Fine with me.
> 
> 
>> It updates the doco (ok?).
> 
> 
> Yes, but perhaps the manual should also say that mi0 is no longer 
> supported.

Now is:

@samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
@value{GDBN} to use the current @dfn{@sc{gdb/mi} interface}
(@pxref{GDB/MI, , The @sc{gdb/mi} Interface}).  The previous @sc{gdb/mi}
interface, included in @value{GDBN} version 5.3, can be selected with
@samp{--interpreter=mi1}.  Earlier @sc{gdb/mi} interfaces
are not supported.


Andrew

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Daniel Jacobowitz]

On Mon, Sep 30, 2002 at 06:06:34PM -0400, Andrew Cagney wrote:
> 
> >>However, should the HEAD hold off on recognizing -i=mi2 until the next 
> >>branch is cut?  On the HEAD, -i=mi evolves by definition.  However, 
> >>-i=mi2 is evolving as well :-(
> >
> >
> >That'd be best I think.  I think that -i=mi2 specifies a fixed standard
> >and we don't have one yet; so how about -i=mi being different from
> >-i=mi1, but not adding -i=mi2 until we're ready to fix the interface?
> 
> I just looked, and I take the idea back.  It means updating NEWS, DOC 
> and testsuite twice - just after the branch (to start the new interface) 
> and just before a branch (to freeze the new interface).
> 
> I think its going to be easier to get it all done once just after the 
> branch.  If someone reports a bug against a YYYYMMDD version of GDB then 
> it's pretty clear that they are not using a released GDB.

OK.  My logic went like:
  It would be nice to be able to use a snapshot, which has
non-MI-syntax-related improvements and fixes in it, without having to
handle a changing interface.

But we can already do that: they use -i=mi1.  So it's all good.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Eli Zaretskii]

On Mon, 30 Sep 2002, Andrew Cagney wrote:

> > Yes, but perhaps the manual should also say that mi0 is no longer 
> > supported.
> 
> Now is:
> 
> @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
> @value{GDBN} to use the current @dfn{@sc{gdb/mi} interface}
> (@pxref{GDB/MI, , The @sc{gdb/mi} Interface}).  The previous @sc{gdb/mi}
> interface, included in @value{GDBN} version 5.3, can be selected with
> @samp{--interpreter=mi1}.  Earlier @sc{gdb/mi} interfaces
> are not supported.

Fine, thanks.

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

Just FYI, I've checked in the attatched.  Unless it's in it isn't 
possible to test that an MI change works with the new mi2 syntax but 
doesn't break the mi1 syntax.

It still leaves unresolved, the issue of when mi2 should be frozen.

Andrew


> Index: ChangeLog
> 2002-09-29  Andrew Cagney  <ac131313@redhat.com>
> 
> 	* NEWS: Mention that MI syntax changed to "mi2" and that "mi0"
> 	syntax has been removed.
> 
> Index: doc/ChangeLog
> 2002-09-29  Andrew Cagney  <ac131313@redhat.com>
> 
> 	* gdb.texinfo (Mode Options): Update --interpreter option.  "mi2"
> 	and "mi1" instead of "mi1" and "mi0".
> 
> Index: mi/ChangeLog
> 2002-09-29  Andrew Cagney  <ac131313@redhat.com>
> 
> 	* mi-main.c (mi2_command_loop): New function.
> 	(mi0_command_loop): Delete function.
> 	(_initialize_mi_main): Recognize, and default to, "mi2".  Do not
> 	recognize "mi0".
> 	* mi-out.c (mi_table_begin): Remove mi0 code.
> 	(mi_table_body, mi_table_end): Ditto.
> 	(mi_table_header, mi_open, mi_close): Ditto.
> 

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jim Ingham]

Andrew,

On Friday, October 25, 2002, at 05:57  PM, 
gdb-patches-digest-help@sources.redhat.com wrote:

> From: Andrew Cagney <ac131313@redhat.com>
> Date: Fri Oct 25, 2002  2:48:09  PM US/Pacific
> To: Jim Ingham <jingham@apple.com>
> Cc: Keith Seitz <keiths@redhat.com>, gdb-patches@sources.redhat.com
> Subject:
>
>
> [Did anyone mention that Apple's mail tool is officially weird?]
> [was a good holiday]
>
>
>>> On Wednesday, October 2, 2002, at 08:01  AM, Keith Seitz wrote:
>>>> On Tue, 1 Oct 2002, Jim Ingham wrote:
>>>> I don't want a tight coupling in TIME, or in the output sequence.  I
>>>> want meta-info which tells me with 100% certainty that this result 
>>>> is
>>>> the result of command foo, that I sent some time in the past, 
>>>> precisely
>>>> so I DON'T have to rely on anything about the sequencing of input or
>>>> output to make this connection.
>>> Ok, but this is exactly what I don't understand: what does it matter 
>>> where
>>> the breakpoint comes from? All that matters is that you have issued a
>>> command, and you don't do anything out of the normaluntil an event 
>>> from
>>> GDB telling you that it has set a breakpoint. You just sit in your 
>>> event
>>> loop waiting for any event (GUI, paint, GDB, blah blah blah).
>
>> In large part, it is just that if I can track cause & effect 
>> unambiguously, everything is much cleaner.  From PB, I issue a 
>> command, I want to tick off when that command succeeded, and gather 
>> all the data from the result I need.  If I get a note back from gdb 
>> saying, "The third command down in the command stream that you 
>> issued, here is the result to it." then I can do this without any 
>> effort.  However, in your proposed implementation, I have to peer at 
>> the command stream and wait both for an anonymous breakpoint created 
>> message, and a for the done message (to know things are formally 
>> done, and because it would be very dangerous to just toss aside bits 
>> of the output stream, since it reduces your chances of catching & 
>> handling errors intelligently.)  Then I have to use some smarts to 
>> tie the breakpoint created message to the particular message I sent 
>> to gdb.  This is harder to do, and fragile.
>
>> In my mind, one of the major advantages of the MI was that it made 
>> this tie between the command you sent and the result that came from 
>> it explicit and unambiguous.  This was in response to a lot of the 
>> pain that we suffered in insight where any random spew from the 
>> command line would get itself inserted into the "results" of the 
>> command you thought you were executing.  You are breaking this tie by 
>> moving the results of a command from the command result to an 
>> untagged asynchronous event.  For breakpoints, this is probably just 
>> an inconvenience.  But if we follow this as a principle, then in more 
>> complex cases, where it is not so easy to tell whether an 
>> asynchronous notification arose from a command initiated by the MI, 
>> or from some other action we will likely start getting confused 
>> again.  For instance, we might have something happening in the 
>> target, or some console command, or something more gnarly like the 
>> results of a breakpoint command which also continued the target while 
>> you thought it was just running...
>
> You mean like 
> http://sources.redhat.com/gdb/papers/libgdb2/wp/gdbtk2.jpg
>

Cute...

> There are two things here:
>
> - events
> - results
>
> And a question of what, if anything, each should be bound two.
>
> For the case in question, I think you're greatest concern is with 
> ensuring that the result of the request is clearly bound to the 
> command completion indication.  With that in mind, would something 
> like:
>
> 	-breakpoint-create
> 	=breakpoint-created,....
> 	=breakpoint-created,....
> 	^done,breakpoint=1
>
> be reasonable?  It clearly binds the created breakpoint with the 
> request while at the same time doesn't treat the creation of this 
> breakpoint any different to the creation of any other breakpoint.

Right.  I think the principle should be that any command that has a 
direct result, that result should be reported in the "done" message of 
the command.  I don't mind that it also get reported as an event.  For 
instance, this means that if something like your listing above occurs, 
I know that the first breakpoint is the one I intended to make, and the 
second one, dunno about.  This will be important, for instance, if we 
ever teach gdb that breaking on template source code generated a whole 
bunch of breakpoints.  The GUI will want to gather up these breakpoints 
and treat them as a single bundle (since if the source line breakpoint 
is deleted in the UI, it will need to delete all these breakpoints).  
So knowing that one of the breakpoint-created events is some odd 
accident would be useful...

>
> I don't know how feasible it is to do this, mind.
>

Shouldn't be hard for the breakpoints, we do it already...

>
> >
> > In short, you are breaking one of the core parts of the MI model, 
> for no very apparent reason.  In this case, it might be benign, but it 
> is a very useful part of the design, and the reasons for doing it are 
> very weak.
>
> The MI was always going to have events and those events were going to 
> be separate from the results.  As a simple example (from the 5.2.1 
> doco):
> http://sources.redhat.com/gdb/download/onlinedocs/gdb_24.html#SEC223
>
> 	Command With Side Effects
> 	-> -symbol-file xyz.exe
> 	<- *breakpoint,nr="3",address="0x123",source="a.c:123"
> 	<- (gdb)
>
> [sic - its missing a ^done].  One reason for this separation of event 
> and result is that we felt we could see far enough ahead to at least 
> realise that the MI would have to handle things like:
>
> 	-interpreter cli "break foo"
> 	=breakpoint-created,...
> 	^done
>
> or even:
>
> 	-interpreter cli "source script"
> 	=breakpoint-created,...
> 	=breakpoint-deleted,...
> 	=running
> 	^done
> 	(gdb)
> 	=stopped,...
> 	=breakpoint-created,...
> 	=running
> 	(gdb)
>
> That is, in the general case, trying to tightly bind MI and events to 
> results wasn't going to be possible.
>
>

Seems better to say that an mi command will usually have a well defined 
result, but may well have unintended consequences as well.  We should 
be able to bind the result to the command token, but not the unintended 
consequences.  It's actually not impossible to do that either, the 
original implementation that I did had all the event-like things added 
as tagged bits to the command result, unless they came after the 
command returned.  But that's not the way Keith chose to implement it, 
which is fine.

Of course, -interpreter-exec (is Keith changing this to -interpreter, 
or did you just type it wrong?) has NO well defined results.  
Everything is an unintended consequence.  For convenience's sake, I 
think I report whether the command has started up the inferior or not, 
but even that could be gotten from events.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

[Did anyone mention that Apple's mail tool is officially weird?]
[was a good holiday]


>> On Wednesday, October 2, 2002, at 08:01  AM, Keith Seitz wrote:
>> 
>>> On Tue, 1 Oct 2002, Jim Ingham wrote:
>>> 
>>> I don't want a tight coupling in TIME, or in the output sequence.  I
>>> want meta-info which tells me with 100% certainty that this result is
>>> the result of command foo, that I sent some time in the past, precisely
>>> so I DON'T have to rely on anything about the sequencing of input or
>>> output to make this connection.
> 
>> 
>> Ok, but this is exactly what I don't understand: what does it matter where
>> the breakpoint comes from? All that matters is that you have issued a
>> command, and you don't do anything out of the normaluntil an event from
>> GDB telling you that it has set a breakpoint. You just sit in your event
>> loop waiting for any event (GUI, paint, GDB, blah blah blah).

> 
> In large part, it is just that if I can track cause & effect unambiguously, everything is much cleaner.  From PB, I issue a command, I want to tick off when that command succeeded, and gather all the data from the result I need.  If I get a note back from gdb saying, "The third command down in the command stream that you issued, here is the result to it." then I can do this without any effort.  However, in your proposed implementation, I have to peer at the command stream and wait both for an anonymous breakpoint created message, and a for the done message (to know things are formally done, and because it would be very dangerous to just toss aside bits of the output stream, since it reduces your chances of catching & handling errors intelligently.)  Then I have to use some smarts to tie the breakpoint created message to the particular message I sent to gdb.  This is harder to do, and fragile.

> In my mind, one of the major advantages of the MI was that it made this tie between the command you sent and the result that came from it explicit and unambiguous.  This was in response to a lot of the pain that we suffered in insight where any random spew from the command line would get itself inserted into the "results" of the command you thought you were executing.  You are breaking this tie by moving the results of a command from the command result to an untagged asynchronous event.  For breakpoints, this is probably just an inconvenience.  But if we follow this as a principle, then in more complex cases, where it is not so easy to tell whether an asynchronous notification arose from a command initiated by the MI, or from some other action we will likely start getting confused again.  For instance, we might have something happening in the target, or some console command, or something more gnarly like the results of a breakpoint command which also continued the target wh
ile you thought it was just running...

You mean like http://sources.redhat.com/gdb/papers/libgdb2/wp/gdbtk2.jpg

There are two things here:

- events
- results

And a question of what, if anything, each should be bound two.

For the case in question, I think you're greatest concern is with 
ensuring that the result of the request is clearly bound to the command 
completion indication.  With that in mind, would something like:

	-breakpoint-create
	=breakpoint-created,....
	=breakpoint-created,....
	^done,breakpoint=1

be reasonable?  It clearly binds the created breakpoint with the request 
while at the same time doesn't treat the creation of this breakpoint any 
different to the creation of any other breakpoint.

I don't know how feasible it is to do this, mind.


 >
 > In short, you are breaking one of the core parts of the MI model, for 
no very apparent reason.  In this case, it might be benign, but it is a 
very useful part of the design, and the reasons for doing it are very weak.

The MI was always going to have events and those events were going to be 
separate from the results.  As a simple example (from the 5.2.1 doco):
http://sources.redhat.com/gdb/download/onlinedocs/gdb_24.html#SEC223

	Command With Side Effects
	-> -symbol-file xyz.exe
	<- *breakpoint,nr="3",address="0x123",source="a.c:123"
	<- (gdb)

[sic - its missing a ^done].  One reason for this separation of event 
and result is that we felt we could see far enough ahead to at least 
realise that the MI would have to handle things like:

	-interpreter cli "break foo"
	=breakpoint-created,...
	^done

or even:

	-interpreter cli "source script"
	=breakpoint-created,...
	=breakpoint-deleted,...
	=running
	^done
	(gdb)
	=stopped,...
	=breakpoint-created,...
	=running
	(gdb)

That is, in the general case, trying to tightly bind MI and events to 
results wasn't going to be possible.

Andrew

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jim Ingham]

On Wednesday, October 2, 2002, at 08:01  AM, Keith Seitz wrote:

> On Tue, 1 Oct 2002, Jim Ingham wrote:
>
>> I don't want a tight coupling in TIME, or in the output sequence.  I
>> want meta-info which tells me with 100% certainty that this result is
>> the result of command foo, that I sent some time in the past, 
>> precisely
>> so I DON'T have to rely on anything about the sequencing of input or
>> output to make this connection.
>
> Ok, but this is exactly what I don't understand: what does it matter 
> where
> the breakpoint comes from? All that matters is that you have issued a
> command, and you don't do anything out of the normaluntil an event from
> GDB telling you that it has set a breakpoint. You just sit in your 
> event
> loop waiting for any event (GUI, paint, GDB, blah blah blah).

In large part, it is just that if I can track cause & effect 
unambiguously, everything is much cleaner.  From PB, I issue a command, 
I want to tick off when that command succeeded, and gather all the data 
from the result I need.  If I get a note back from gdb saying, "The 
third command down in the command stream that you issued, here is the 
result to it." then I can do this without any effort.  However, in your 
proposed implementation, I have to peer at the command stream and wait 
both for an anonymous breakpoint created message, and a for the done 
message (to know things are formally done, and because it would be very 
dangerous to just toss aside bits of the output stream, since it 
reduces your chances of catching & handling errors intelligently.)  
Then I have to use some smarts to tie the breakpoint created message to 
the particular message I sent to gdb.  This is harder to do, and 
fragile.

In my mind, one of the major advantages of the MI was that it made this 
tie between the command you sent and the result that came from it 
explicit and unambiguous.  This was in response to a lot of the pain 
that we suffered in insight where any random spew from the command line 
would get itself inserted into the "results" of the command you thought 
you were executing.  You are breaking this tie by moving the results of 
a command from the command result to an untagged asynchronous event.  
For breakpoints, this is probably just an inconvenience.  But if we 
follow this as a principle, then in more complex cases, where it is not 
so easy to tell whether an asynchronous notification arose from a 
command initiated by the MI, or from some other action we will likely 
start getting confused again.  For instance, we might have something 
happening in the target, or some console command, or something more 
gnarly like the results of a breakpoint command which also continued 
the target while you thought it was just running...

In short, you are breaking one of the core parts of the MI model, for 
no very apparent reason.  In this case, it might be benign, but it is a 
very useful part of the design, and the reasons for doing it are very 
weak.

>
> Insight has used a method exactly like this now for over a year. When a
> breakpoint is set, Insight tells gdb to set it. It then returns to the
> command loop. It doesn't do anything else. It's not waiting for 
> anything.
> When the breakpoint event comes from gdb, it creates its breakpoint 
> object
> and passes it around. The source window gets it and places a 
> breakpoint at
> the appropriate place. I can only assume that you've got private data 
> that
> you need to associate with commands and that this data is lost when
> returning to the event loop.

Not quite.  Rather we want to issue commands in batches, and then link 
the results of the commands back up to the individual commands.  This 
is often a very convenient way to proceed.  And I would rather have the 
linkage be explicit, because matching the commands to results by 
inspecting the sequencing of the result is fragile and error-prone.

>
> Please help me understand why it is so important to know exactly what
> command prompted a breakpoint event. I still just don't get it. Can you
> give me a specific example of when it would be useful to know that 
> command
> A elicited breakpoint event A' instead of command B?

Remember that PB persists over individual runs of the gdb debugger (and 
can, in fact, be running multiple copies of gdb, one for each project). 
  Also,we keep a Breakpoints window that persists between runs of PB, so 
the user can have all his/her favorite breakpoints persist over PB 
sessions.  So we have to have an object on the PB side that represents 
each breakpoint before we have even thought about starting up gdb.  
Each one of these PB breakpoints is going to result in a gdb breakpoint 
at some time.  When I go to take the PB breakpoint object & insert it 
into the current instance of the gdb debugger, I would like to get the 
right breakpoint number back into the associated PB breakpoint object.  
I can very easily do this if I can tie the results of the command that 
sends the breakpoint to gdb to the initial command.  Otherwise I have 
to do unnecessary work whose only benefit is it gives me a chance to 
make a mistake somewhere.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Stan Shebs]

Keith Seitz wrote:

>
><devil's advocate>
>As far as the versioning thing goes, I must say that I don't really care, 
>(not that my opinion matters), but I can understand why some on this list 
>would be less sympathetic with objections to dropping mi0 coming from 
>Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of 
>stuff, but only managed to "submit" a giant distribution tarball of their 
>modified GDB. I wouldn't be too suprised if some thought that Apple was 
>taking advantage of the public's work. Mind you, I'm not saying that any 
>of this is true, but I wouldn't be suprised if some one reading this list 
>felt that way.
></devil's advocate>
>
If you're saying it, then there are probably others thinking it, and
so I'll respond that this is both unfair and ignorant.  Apple is the
only major system vendor using GCC and GDB as their primary development
tools, and we have a set of considerations not seen by GNU/Linux,
Cisco, HP, etc.

For instance, we have massive legacy, both from NeXT and from the old
MacOS world.  We also have hundreds of fulltime engineers who can't
get their jobs done if GDB doesn't, say, display a thread local variable
correctly.  We also have to provide tools for external developers coming
from the various existing Mac environments, such as MPW and CW, many of
them have expectations vastly different than what GNU traditionally
provides, and if you tell them "tough", then they stop developing for
the Mac, which is not acceptable.

I've dealt with this for a couple years in the GCC context, and the
situation is that even if we were to offer every single local change,
many of them would be turned down, which means that we always have a
constant overhead time to maintain our changes, depending on the churn
in FSF code.  So when we have to deal with gratuitous change, that eats
into the time that could have been spent making patches for submission.
It's a real chicken-and-egg problem, and in the compiler group we've
been fortunate in having extra people to do some of this work while
still meeting our other obligations.

So let's all stay honest and aboveboard about what we're all doing and
why, and in turn not impugn the motives and activities of our
colleagues.  We can accomplish a lot more working with rather than
against each other.

Stan

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Keith Seitz]

On Tue, 1 Oct 2002, Jim Ingham wrote:

> I don't want a tight coupling in TIME, or in the output sequence.  I 
> want meta-info which tells me with 100% certainty that this result is 
> the result of command foo, that I sent some time in the past, precisely 
> so I DON'T have to rely on anything about the sequencing of input or 
> output to make this connection.

Ok, but this is exactly what I don't understand: what does it matter where 
the breakpoint comes from? All that matters is that you have issued a 
command, and you don't do anything out of the normaluntil an event from 
GDB telling you that it has set a breakpoint. You just sit in your event 
loop waiting for any event (GUI, paint, GDB, blah blah blah).

Insight has used a method exactly like this now for over a year. When a 
breakpoint is set, Insight tells gdb to set it. It then returns to the 
command loop. It doesn't do anything else. It's not waiting for anything. 
When the breakpoint event comes from gdb, it creates its breakpoint object 
and passes it around. The source window gets it and places a breakpoint at 
the appropriate place. I can only assume that you've got private data that 
you need to associate with commands and that this data is lost when 
returning to the event loop.

Please help me understand why it is so important to know exactly what 
command prompted a breakpoint event. I still just don't get it. Can you 
give me a specific example of when it would be useful to know that command 
A elicited breakpoint event A' instead of command B?

Sorry.
Keith

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jason Molenda]

On Tue, Oct 01, 2002 at 04:42:28PM -0700, Keith Seitz wrote:

> <devil's advocate>
>[...]
> Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of 
> stuff, but only managed to "submit" a giant distribution tarball of their 
> modified GDB. I wouldn't be too suprised if some thought that Apple was 
> taking advantage of the public's work. Mind you, I'm not saying that any 
> of this is true, but I wouldn't be suprised if some one reading this list 
> felt that way.
> </devil's advocate>


This is definitely off-topic and I should just let it go... But this
isn't a fair representation of reality.  I think Keith knows it, and
I think all the gdb folks who know Jim know it.  The gdb group at
Apple is not large and has had tremendous struggles to get gdb working
correctly for its developers on the MacOS X platform -- there has
been literally no time left over.  Apple management is very supportive
of moving our fixes, enhancements and changes to the FSF as much
as possible -- as anyone would sensibly be -- but it's a simple matter
of not having the time to make it happen so far.

As for the source dump, you know very well that Andrew asked for
that, and I provided it right away.  (Incidentally, I'm not one of
these hard-working Apple gdb programmers, and even I couldn't find
time to make up the original tarball until a weekend.)

I think you can see Apple's committment to working with the free
software community in gcc more easily -- we've got more people
working on the compiler there and it is an obvious priority to
participate in the compiler's development and enhancement.  The
compiler and debugger groups are under the same management
structure - they're clued in that this is a necessary way to 
operate in the long term.


Back in the day, Cygnus was periodically flamed for being evil
software hoarders by various unclueful people because we weren't
releasing our local changes in the timeframe or manner that the
flamers wanted us to.  Keith, you should know better.

Jason

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jim Ingham]

Keith,

On Tuesday, October 1, 2002, at 04:42  PM, Keith Seitz wrote:

> On Tue, 1 Oct 2002, Jim Ingham wrote:
>
>> BTW, I haven't seen the actual change Keith is planning here.  Will he
>> be sticking the command sequence cookie in the async result?  His
>> example didn't show the cookies.
>
> For the record, the proposed change would look like:
>
> (gdb)
> 200-break-insert main
> =breakpoint-create,number="1"
> 200^done
> (gdb)
>
>> Seems to me that reporting command results as an async notification
>> means that we are breaking the tie between the command and its 
>> results.
>
> And is that necessarily bad? (More on my confusion below...)
>
>>   It was very nice that I could issue a bunch of commands at some 
>> point
>> in the GUI code, then at another place gather up the results, and 
>> match
>> them to the initial commands by using the sequence ID's.
>
> I'm afraid that I'm not following. Could you please expound? Why would
> you want a tight coupling of commands and their results? What's wrong 
> with
> just issuing a command at GDB and waiting for GDB to tell you that
> it's done something? It seems to me that the less serialization that a 
> UI
> does, the more time it has to spend in its event loop and the more
> responsive it will feel to the user (barring the java way: create a
> freakin' thread for everything).

I don't want a tight coupling in TIME, or in the output sequence.  I 
want meta-info which tells me with 100% certainty that this result is 
the result of command foo, that I sent some time in the past, precisely 
so I DON'T have to rely on anything about the sequencing of input or 
output to make this connection.

Suppose I have a canned startup sequence that I send to gdb when the 
user starts up.  This startup sequence sets a bunch of environment 
variables, does some other accounting and also retrieves the saved 
breakpoint list from the project, and sends those to the target.  In 
the PB code, we make a bunch of command objects - one for each of these 
commands - put them on a queue of outstanding commands, stick the 
actual gdb command in a buffer, then fire the whole lot off to gdb.  
Then we sit at the other end of the communication loop sucking commands 
back from gdb.  Each time we get a result, we use the cookie to match 
it to the command object, give the command object its data, and it does 
whatever it needs with it (for instance, create a real breakpoint 
object, and stick it in our list of breakpoints).  Doing this is very 
straightforward, we can always map the results to the command that sent 
them with NO guesswork.  And anything else that shows up is some 
asynchronous result that can be treated specially - some error 
condition or whatever.

As soon as I have to guess the connection between results from gdb and 
the command that originated them by position in the gdb output stream, 
this very nice model breaks down.

>
>> In the new way of doing things, we have to parse more carefully, and
>> assume that the =breakpoint-create that we just got was the one that
>> came from the -break-insert in the output just above it.  It makes the
>> client stream parser have to be more stateful that in the mi0 version,
>> which doesn't seem to me all that good an idea.  If the async event 
>> has
>> the cookie in it, this will be a little better, though it still means 
>> I
>> have a two-step accumulation phase for each command (wait for the 
>> async
>> result with the right cookie, then the done with the right cookie...)
>
> Ditto the above. Maybe -break-insert and =breakpoint-create are bad
> examples(?), but I am not able to imagine why it would matter which
> command elicited the notification. Commands are issued, and something
> happens. The only case I can imagine where this is important is when
> an error occurs setting the breakpoint, but MI will (and will
> continue) to report errors immediately.

In the break case, on the UI side I have something that, until I get 
the breakpoint number back from gdb, I can't do anything with.  At the 
time I issue the breakpoint command, I can't make a complete break 
object on the GUI side.  So a very convenient way to handle this is 
just to tell myself I have a pending command, and when the result comes 
back, actually make the now useful breakpoint object.

If the command results have the command cookie in them, I just wait 
till I get that cookie back, suck the data in and make the breakpoint 
object.  In your new method, I have to keep a more careful eye on the 
output stream, fish the =breakpoint-create off the stream, know somehow 
(either because I only ever get to have one outstanding breakpoint, or 
because I keep a list of breakpoints in order of issuing) which command 
it actually goes to, continue to wait for the ^done - 'cause there's 
many a slip..., then finally make the object.  Much more tedious.

Plus, what if there is an error?  Then presumably  I will get the 
^error, but NOT the =breakpoint-create...

The other way to do it, is just to issue a bunch of stuff down the 
pipe, but not build any objects watching for results.  Then I hang 
around on the UI side going "Oh, boy, I just got a breakpoint, yuk, 
yuk..." and make the object.  Not very reliable, however.

You are just making life much harder for the client.  It is REALLY nice 
to have results match up with commands.  You want to minimize knowledge 
of the output flow, and your method of doing things actually requires 
more knowledge...  The more I think about it the worse idea it appears 
to me...

>
> Maybe something related to async targets? (BTW, there is no reason why
> I/we cannot/could not put the old behavior back for an MI0 target, if
> 'mi0' were sticking  around, which is a decision I want nothing to do
> with, actually.) One is still pretty screwed, though, when
> "interpreter-exec" is used, unless we revert from async notification 
> back
> to serial notification via hook hack that you're using.
>
> <devil's advocate>
> As far as the versioning thing goes, I must say that I don't really 
> care,
> (not that my opinion matters), but I can understand why some on this 
> list
> would be less sympathetic with objections to dropping mi0 coming from
> Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot 
> of
> stuff, but only managed to "submit" a giant distribution tarball of 
> their
> modified GDB. I wouldn't be too suprised if some thought that Apple was
> taking advantage of the public's work. Mind you, I'm not saying that 
> any
> of this is true, but I wouldn't be suprised if some one reading this 
> list
> felt that way.
> </devil's advocate>

This is unhelpful.  The real point is that you CAN'T know who all the 
users of the MI are.  If the MI is well done, they never need tell you 
that they are using it, nor should they.  And requiring anyone planning 
to use the MI to follow gdb-patches closely that they might know when 
their software is likely to stop working is silly.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Keith Seitz]

On Tue, 1 Oct 2002, Jim Ingham wrote:

> BTW, I haven't seen the actual change Keith is planning here.  Will he 
> be sticking the command sequence cookie in the async result?  His 
> example didn't show the cookies.

For the record, the proposed change would look like:

(gdb)
200-break-insert main
=breakpoint-create,number="1"
200^done
(gdb) 

> Seems to me that reporting command results as an async notification 
> means that we are breaking the tie between the command and its results. 

And is that necessarily bad? (More on my confusion below...)

>   It was very nice that I could issue a bunch of commands at some point 
> in the GUI code, then at another place gather up the results, and match 
> them to the initial commands by using the sequence ID's.

I'm afraid that I'm not following. Could you please expound? Why would 
you want a tight coupling of commands and their results? What's wrong with 
just issuing a command at GDB and waiting for GDB to tell you that
it's done something? It seems to me that the less serialization that a UI 
does, the more time it has to spend in its event loop and the more 
responsive it will feel to the user (barring the java way: create a 
freakin' thread for everything).

> In the new way of doing things, we have to parse more carefully, and 
> assume that the =breakpoint-create that we just got was the one that 
> came from the -break-insert in the output just above it.  It makes the 
> client stream parser have to be more stateful that in the mi0 version, 
> which doesn't seem to me all that good an idea.  If the async event has 
> the cookie in it, this will be a little better, though it still means I 
> have a two-step accumulation phase for each command (wait for the async 
> result with the right cookie, then the done with the right cookie...)

Ditto the above. Maybe -break-insert and =breakpoint-create are bad 
examples(?), but I am not able to imagine why it would matter which 
command elicited the notification. Commands are issued, and something 
happens. The only case I can imagine where this is important is when 
an error occurs setting the breakpoint, but MI will (and will 
continue) to report errors immediately.

Maybe something related to async targets? (BTW, there is no reason why 
I/we cannot/could not put the old behavior back for an MI0 target, if 
'mi0' were sticking  around, which is a decision I want nothing to do 
with, actually.) One is still pretty screwed, though, when 
"interpreter-exec" is used, unless we revert from async notification back 
to serial notification via hook hack that you're using.

<devil's advocate>
As far as the versioning thing goes, I must say that I don't really care, 
(not that my opinion matters), but I can understand why some on this list 
would be less sympathetic with objections to dropping mi0 coming from 
Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of 
stuff, but only managed to "submit" a giant distribution tarball of their 
modified GDB. I wouldn't be too suprised if some thought that Apple was 
taking advantage of the public's work. Mind you, I'm not saying that any 
of this is true, but I wouldn't be suprised if some one reading this list 
felt that way.
</devil's advocate>

Keith

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jim Ingham]

Andrew,

On Tuesday, October 1, 2002, at 03:10  PM, Andrew Cagney wrote:

>> I am a little confused here.  One of the design points for the MI is 
>> the ability to add information to the commands without requiring a 
>> change in the clients (unless, of course, they wanted to use the new 
>> information).  That should mean that we have set up a situation where 
>> we can change the mi in substantial ways without having to demand 
>> that clients rewrite their code to use MI.  Shouldn't that mean that 
>> we can go a long way without having to make incompatible changes?  
>> And so, imposing the burden on ourselves of not jerking clients 
>> around all the time would not be such a big deal, and perhaps worth 
>> the inconvenience it would cause the MI developers?
>
> Yes, that's the theory.  There are always problems though:
>
> - for some commands, their output is simply bogus.  See gdb/672
> > > - var-update syntax is:
>   ^done,changelist={name="var3",in_scope="true",type_changed="false",
>      name="var2",in_scope="true",type_changed="false"}
> Notice how a single tuple contains several "name" fields :-(  JeffJ's 
> currently comming up with a patch that will preserve the current 
> behavior.

This was putatively bogus, but very easy to parse.  It didn't even 
annoy Rab, when he was first doing this...

>
> - some parts of the interface were technically flawed.
> The breakpoint event stuff that KeithS changed (but not in a backward 
> compatible way :-().  Not fixing this, further entrenches a flawed 
> model :-(  The only error in that change was not preserving the old 
> output when mi1 :-(

BTW, I haven't seen the actual change Keith is planning here.  Will he 
be sticking the command sequence cookie in the async result?  His 
example didn't show the cookies.

Seems to me that reporting command results as an async notification 
means that we are breaking the tie between the command and its results. 
  It was very nice that I could issue a bunch of commands at some point 
in the GUI code, then at another place gather up the results, and match 
them to the initial commands by using the sequence ID's.

In the new way of doing things, we have to parse more carefully, and 
assume that the =breakpoint-create that we just got was the one that 
came from the -break-insert in the output just above it.  It makes the 
client stream parser have to be more stateful that in the mi0 version, 
which doesn't seem to me all that good an idea.  If the async event has 
the cookie in it, this will be a little better, though it still means I 
have a two-step accumulation phase for each command (wait for the async 
result with the right cookie, then the done with the right cookie...)



>
> Fixing either of these involves significant change to MI's output, but 
> it, I think, is for the better.
>
>> As a client of the MI, this means that in a year or so I have to 
>> expect to rewrite code that works just fine, because you have deleted 
>> the support for it from gdb; or carry the burden of maintaining mi1 
>> as patches to the gdb sources.  And longer term, I can expect to do 
>> this again next year, unless things "stabilize" before then, which 
>> they may or may not do.  This doesn't sound appetizing to me.
>> The MI is a public interface to gdb - and the only really useful one 
>> we offer to external clients who are not Human beings right now.  It 
>> has been around in gdb, and we have been using it contentedly, for a 
>> couple of years now.  A retroactively stated policy of instability in 
>> this interface (including the vanishing of useful variants at odd 
>> intervals) seems very unfair to those who have been using it right 
>> along, as well as being one which can only slow its uptake in >> general.
>
> What we're seeing here is the fallout that results from a number of 
> players creating localized GDBs.  GDB developers have started looking 
> at the underlying problems that Apple and others encountered, and are 
> trying to fix them.  Regretably, per above, this is going to need some 
> short term change.

Just because K&R C kind of sucked, however, doesn't mean that most 
compiler vendors got to drop support for it...

Alternatively, I don't know why the planning model for the changes 
seems to be - we will change a bit, declare a version, change a bit 
more, declare another incompatible version and drop the first version, 
rinse and repeat...  In the face of the fact that you most 
unfortunately have users already, I think you should decide to work out 
the changes for whatever time it takes for you to come up with a 
version you are happy with, then stick with that for a product 
lifecycle-type-timescale, not a patch release timescale.  That way 
people who plan to use this stuff can actually plan their use of it...

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

> I am a little confused here.  One of the design points for the MI is the ability to add information to the commands without requiring a change in the clients (unless, of course, they wanted to use the new information).  That should mean that we have set up a situation where we can change the mi in substantial ways without having to demand that clients rewrite their code to use MI.  Shouldn't that mean that we can go a long way without having to make incompatible changes?  And so, imposing the burden on ourselves of not jerking clients around all the time would not be such a big deal, and perhaps worth the inconvenience it would cause the MI developers?

Yes, that's the theory.  There are always problems though:

- for some commands, their output is simply bogus.  See gdb/672
 > > - var-update syntax is:
   ^done,changelist={name="var3",in_scope="true",type_changed="false",
      name="var2",in_scope="true",type_changed="false"}
Notice how a single tuple contains several "name" fields :-(  JeffJ's 
currently comming up with a patch that will preserve the current behavior.

- some parts of the interface were technically flawed.
The breakpoint event stuff that KeithS changed (but not in a backward 
compatible way :-().  Not fixing this, further entrenches a flawed model 
:-(  The only error in that change was not preserving the old output 
when mi1 :-(

Fixing either of these involves significant change to MI's output, but 
it, I think, is for the better.

> As a client of the MI, this means that in a year or so I have to expect to rewrite code that works just fine, because you have deleted the support for it from gdb; or carry the burden of maintaining mi1 as patches to the gdb sources.  And longer term, I can expect to do this again next year, unless things "stabilize" before then, which they may or may not do.  This doesn't sound appetizing to me.
> 
> The MI is a public interface to gdb - and the only really useful one we offer to external clients who are not Human beings right now.  It has been around in gdb, and we have been using it contentedly, for a couple of years now.  A retroactively stated policy of instability in this interface (including the vanishing of useful variants at odd intervals) seems very unfair to those who have been using it right along, as well as being one which can only slow its uptake in general.

What we're seeing here is the fallout that results from a number of 
players creating localized GDBs.  GDB developers have started looking at 
the underlying problems that Apple and others encountered, and are 
trying to fix them.  Regretably, per above, this is going to need some 
short term change.

It is just a shame that this process wasn't started long ago.

Andrew

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jim Ingham]

Andrew,

On Tuesday, October 1, 2002, at 01:25  PM, Andrew Cagney wrote:

>> This is only partly true.  We are actually pretty conservative about 
>> changing command output.  We haven't broken annotate for a while, 
>> IIRC.  The mi is more like the command output, and I think we should 
>> have the same level of conservatism about this.
>
> One of the motivations behind the MI output was that a parser could be 
> written in a way that allowed it to discard anything it didn't 
> recognize.
>
> For instance: additional events, or additional output fields should 
> both simply be discarded.  They shouldn't be viewed as MI changes.
>
> The thing that is triggering mi2 is the changes to actual responses 
> (breakpoints as you pointed out but also others.).
>
> Anyway, at the time of each GDB release, a decision should be made 
> about freezing the current MI interface and starting a new one.  Here, 
> we've frozen mi1 and moved onto mi2's development.  At some point in 
> the future mi2 will be frozen and development will move to mi3 (I 
> strongly suspect it will be pretty quick - 5.4/6.0).  After a freeze, 
> the old syntax should hang around for a limited period of time.

I am a little confused here.  One of the design points for the MI is 
the ability to add information to the commands without requiring a 
change in the clients (unless, of course, they wanted to use the new 
information).  That should mean that we have set up a situation where 
we can change the mi in substantial ways without having to demand that 
clients rewrite their code to use MI.  Shouldn't that mean that we can 
go a long way without having to make incompatible changes?  And so, 
imposing the burden on ourselves of not jerking clients around all the 
time would not be such a big deal, and perhaps worth the inconvenience 
it would cause the MI developers?

>
> The pratical translation of this is  ``how long before the mi1-*.exp 
> files can be deleted''?  My guess is two releases - here 5.3 and 
> 5.4/6.0. That means that 5.5/6.0 (in roughly a year) there will be 
> released a GDB  that doesn't support "mi1" -- for GDB I think that is 
> a long time!

As a client of the MI, this means that in a year or so I have to expect 
to rewrite code that works just fine, because you have deleted the 
support for it from gdb; or carry the burden of maintaining mi1 as 
patches to the gdb sources.  And longer term, I can expect to do this 
again next year, unless things "stabilize" before then, which they may 
or may not do.  This doesn't sound appetizing to me.

The MI is a public interface to gdb - and the only really useful one we 
offer to external clients who are not Human beings right now.  It has 
been around in gdb, and we have been using it contentedly, for a couple 
of years now.  A retroactively stated policy of instability in this 
interface (including the vanishing of useful variants at odd intervals) 
seems very unfair to those who have been using it right along, as well 
as being one which can only slow its uptake in general.


Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

> This is only partly true.  We are actually pretty conservative about changing command output.  We haven't broken annotate for a while, IIRC.  The mi is more like the command output, and I think we should have the same level of conservatism about this.

One of the motivations behind the MI output was that a parser could be 
written in a way that allowed it to discard anything it didn't recognize.

For instance: additional events, or additional output fields should both 
simply be discarded.  They shouldn't be viewed as MI changes.

The thing that is triggering mi2 is the changes to actual responses 
(breakpoints as you pointed out but also others.).

Anyway, at the time of each GDB release, a decision should be made about 
freezing the current MI interface and starting a new one.  Here, we've 
frozen mi1 and moved onto mi2's development.  At some point in the 
future mi2 will be frozen and development will move to mi3 (I strongly 
suspect it will be pretty quick - 5.4/6.0).  After a freeze, the old 
syntax should hang around for a limited period of time.

The pratical translation of this is  ``how long before the mi1-*.exp 
files can be deleted''?  My guess is two releases - here 5.3 and 
5.4/6.0. That means that 5.5/6.0 (in roughly a year) there will be 
released a GDB  that doesn't support "mi1" -- for GDB I think that is a 
long time!

Andrew

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jim Ingham]

Andrew,

On Tuesday, October 1, 2002, at 09:29  AM, Andrew Cagney wrote:

>> Hi, all...
>> The changes from mi0 to mi1 were pretty trivial.  So clients (in my 
>> case Project Builder) can fairly easily accommodate the removal of 
>> the mi0 interpreter.  I am not suggesting that we reinstate that.
>> However, the mi2 is shaping up to be a pretty big change (among other 
>> things, command results are differently reported in toto, as well as 
>> some command results changing format.)  Converting PB from mi1 to mi2 
>> is going to be a lot of work.   And because of its nature, there is 
>> no a priori way to tell what all the clients are - and not all the 
>> clients will closely read the gdb-patches mailing list...
>
> mi2 is bug fixes on mi1.  However, at the same time it is gaining some 
> of the missing functionality.  Its just that more bugs and more 
> missing functionality are being worked on.  To put it simply, about 
> time!

Well, mi1 was a moving target, so "bug fixes on mi1" is a little hard 
to quantify.  But the change that Keith proposed - which started off 
the bump to mi2 discussion - was to move command result reporting for 
things like -break-insert from the ^done to the gdb event.  This has a 
big effect on how a client uses the mi.

>
> cf the patch to pr gdb/672 where the output was straight bogus (it 
> contained the equivalent of {name="foo", name="bar", name="baz"}.  
> JeffJ has been asked to preserve the old (broken) behavior.  I should 
> note it was very tempting to not make this request since the old 
> behavior was broken and should have been bug-reported and fixed long 
> long ago.
>
>> Because of this, I am a little nervous at the easy way we are talking 
>> about deleting older versions of the mi.  I think it is our 
>> responsibility to careful, and only release versions of the mi that 
>> we want to support, not the clients of the mi's responsibility to 
>> change their code every time we decide we are tired of supporting the 
>> test cases from one of the other versions we have previously 
>> promulgated...  The mi loses much of its appeal if it means you are 
>> going to have to occasionally rework parts of your client that 
>> already work just fine, or suffer permanent fork-hood for your gdb.
>
> I was ment to delete mi0 something like a year ago.  I'm running a 
> little late on that one :-)
>
>> I agree with Daniel that we should hold off on declaring a real mi2 
>> till we have something we are willing to support long term.   And for 
>> the mi to be useful, I think we need to stick to only putting out 
>> named versions that we are willing to support.
>
> Part of the nature of GDB is that it is constantly evolving.  MI is 
> going to be (like it or not) part of that evolution.  Each new GDB 
> release will see enhancements and bug fixes and MI uses will need to 
> be accomodating to that.

This is only partly true.  We are actually pretty conservative about 
changing command output.  We haven't broken annotate for a while, IIRC. 
  The mi is more like the command output, and I think we should have the 
same level of conservatism about this.

>
> In return for this accomodation GDB are trying to preserve a given MI 
> interface for at least two release cycles.  Part of is the very strong 
> emphasis on testcases and documentation.  If you feel that things are 
> lacking in this area then, perhaphs something to contribute to, is the 
> documentation and testing infrastructure for MI (did the apple 
> droppings contain any new tests?).

No, we haven't worked on this.  It is something we know we need to do, 
but for now we have been using Project Builder as our mi tester (it 
exercises a fair bit of the functionality, and catches most of the 
things we break).

>
> Over time, the MI interface should also stablize.
>

I agree.  I am just arguing that we should mark stable points and then 
think hard before we delete them.  Otherwise while it is waiting to 
stabilize, folks will be reasonably a little chary about using it...

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney]

> Hi, all...
> 
> The changes from mi0 to mi1 were pretty trivial.  So clients (in my case Project Builder) can fairly easily accommodate the removal of the mi0 interpreter.  I am not suggesting that we reinstate that.
> 
> However, the mi2 is shaping up to be a pretty big change (among other things, command results are differently reported in toto, as well as some command results changing format.)  Converting PB from mi1 to mi2 is going to be a lot of work.   And because of its nature, there is no a priori way to tell what all the clients are - and not all the clients will closely read the gdb-patches mailing list...

mi2 is bug fixes on mi1.  However, at the same time it is gaining some 
of the missing functionality.  Its just that more bugs and more missing 
functionality are being worked on.  To put it simply, about time!

cf the patch to pr gdb/672 where the output was straight bogus (it 
contained the equivalent of {name="foo", name="bar", name="baz"}.  JeffJ 
has been asked to preserve the old (broken) behavior.  I should note it 
was very tempting to not make this request since the old behavior was 
broken and should have been bug-reported and fixed long long ago.

> Because of this, I am a little nervous at the easy way we are talking about deleting older versions of the mi.  I think it is our responsibility to careful, and only release versions of the mi that we want to support, not the clients of the mi's responsibility to change their code every time we decide we are tired of supporting the test cases from one of the other versions we have previously promulgated...  The mi loses much of its appeal if it means you are going to have to occasionally rework parts of your client that already work just fine, or suffer permanent fork-hood for your gdb.

I was ment to delete mi0 something like a year ago.  I'm running a 
little late on that one :-)

> I agree with Daniel that we should hold off on declaring a real mi2 till we have something we are willing to support long term.   And for the mi to be useful, I think we need to stick to only putting out named versions that we are willing to support.

Part of the nature of GDB is that it is constantly evolving.  MI is 
going to be (like it or not) part of that evolution.  Each new GDB 
release will see enhancements and bug fixes and MI uses will need to be 
accomodating to that.

In return for this accomodation GDB are trying to preserve a given MI 
interface for at least two release cycles.  Part of is the very strong 
emphasis on testcases and documentation.  If you feel that things are 
lacking in this area then, perhaphs something to contribute to, is the 
documentation and testing infrastructure for MI (did the apple droppings 
contain any new tests?).

Over time, the MI interface should also stablize.

Andrew

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jim Ingham]

Hi, all...

The changes from mi0 to mi1 were pretty trivial.  So clients (in my 
case Project Builder) can fairly easily accommodate the removal of the 
mi0 interpreter.  I am not suggesting that we reinstate that.

However, the mi2 is shaping up to be a pretty big change (among other 
things, command results are differently reported in toto, as well as 
some command results changing format.)  Converting PB from mi1 to mi2 
is going to be a lot of work.   And because of its nature, there is no 
a priori way to tell what all the clients are - and not all the clients 
will closely read the gdb-patches mailing list...

Because of this, I am a little nervous at the easy way we are talking 
about deleting older versions of the mi.  I think it is our 
responsibility to careful, and only release versions of the mi that we 
want to support, not the clients of the mi's responsibility to change 
their code every time we decide we are tired of supporting the test 
cases from one of the other versions we have previously promulgated...  
The mi loses much of its appeal if it means you are going to have to 
occasionally rework parts of your client that already work just fine, 
or suffer permanent fork-hood for your gdb.

I agree with Daniel that we should hold off on declaring a real mi2 
till we have something we are willing to support long term.   And for 
the mi to be useful, I think we need to stick to only putting out named 
versions that we are willing to support.

Jim

> On Mon, Sep 30, 2002 at 11:03:55AM -0400, Andrew Cagney wrote:
>>
>>>>>
>>>>> Are you planning to revert mi1 then?
>>>
>>>>
>>>> Que?
>>>
>>>
>>> "mi2" changes have been sneaking in.  Are you planning to revert 
>>> them -
>>> create an "mi1" which matches what mi1 actually was.
>>
>> It's a bit late for that.  Someone should audit the changes made so 
>> far
>> and identify which caused syntax changes and update accordingly.  
>> Fixes
>> could, perhaphs be pushed into 5.3 (but I don't have the time).
>>
>>> Otherwise, where is the line drawn to mark the interface version as
>>> final?  It seems to me that the default shouldn't be evolving, that
>>> -i=mi should default to a fixed point until the next version is
>>> running.
>>
>> I think a line is drawn when each release is made.  I'd expect an MI
>> client to explicitly specify -i=miN (where N was formally released)
>> rather than trust -i=mi.
>>
>> However, should the HEAD hold off on recognizing -i=mi2 until the next
>> branch is cut?  On the HEAD, -i=mi evolves by definition.  However,
>> -i=mi2 is evolving as well :-(
>
> That'd be best I think.  I think that -i=mi2 specifies a fixed standard
> and we don't have one yet; so how about -i=mi being different from
> -i=mi1, but not adding -i=mi2 until we're ready to fix the interface?
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb