Re: MI: type prefixes for values

Re: MI: type prefixes for values

[Nick Roberts]

 > Also, I note that gdb is currently inconsitent even within itself:
 > 
 >     (gdb)
 >     -thread-select 2
 >     ^done,new-thread-id="2",frame={level="0",func="thread",
 >     args=[{name="p",value="0x0"}],..........
 >    (gdb)
 >    -stack-list-arguments 1 0 0
 >    ^done,stack-args=[frame={level="0",
 >    args=[{name="p",value="(void *) 0x0"}]}]
 > 
 > Note that first output has "0x0" as value of 'p', and the second has 
 > "(void *)0x0". 

Here's a patch that doesn't print the type with the value for 
-stack-list-arguments and -stack-list-list-locals (they both use
list_args_or_locals).

The screenshot http://www.inet.net.nz/~nickrob/gdb-ui.png shows the
duplication that arises from the current code (in the upper right hand
window (locals of emacs) of the Emacs frame).

Nick


2006-03-12  Nick Roberts  <nickrob@snap.net.nz>

	* mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print
	instead of print_variable_value so that type doesn't get printed
	with value.


*** mi-cmd-stack.c	05 Jan 2006 10:56:18 +1300	1.29
--- mi-cmd-stack.c	12 Mar 2006 19:44:08 +1300	
*************** list_args_or_locals (int locals, int val
*** 278,283 ****
--- 278,284 ----
  	    {
  	      struct cleanup *cleanup_tuple = NULL;
  	      struct symbol *sym2;
+ 	      struct value *val;
  	      if (values != PRINT_NO_VALUES)
  		cleanup_tuple =
  		  make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
*************** list_args_or_locals (int locals, int val
*** 300,312 ****
  		      && TYPE_CODE (type) != TYPE_CODE_STRUCT
  		      && TYPE_CODE (type) != TYPE_CODE_UNION)
  		    {
! 		      print_variable_value (sym2, fi, stb->stream);
  		      ui_out_field_stream (uiout, "value", stb);
  		    }
  		  do_cleanups (cleanup_tuple);
  		  break;
  		case PRINT_ALL_VALUES:
! 		  print_variable_value (sym2, fi, stb->stream);
  		  ui_out_field_stream (uiout, "value", stb);
  		  do_cleanups (cleanup_tuple);
  		  break;
--- 301,317 ----
  		      && TYPE_CODE (type) != TYPE_CODE_STRUCT
  		      && TYPE_CODE (type) != TYPE_CODE_UNION)
  		    {
! 		      val = read_var_value (sym2, fi);
! 		      common_val_print
! 			(val, stb->stream, 0, 0, 2, Val_no_prettyprint);
  		      ui_out_field_stream (uiout, "value", stb);
  		    }
  		  do_cleanups (cleanup_tuple);
  		  break;
  		case PRINT_ALL_VALUES:
! 		  val = read_var_value (sym2, fi);
! 		  common_val_print
! 		    (val, stb->stream, 0, 0, 2, Val_no_prettyprint);
  		  ui_out_field_stream (uiout, "value", stb);
  		  do_cleanups (cleanup_tuple);
  		  break;

Re: MI: type prefixes for values

[Vladimir Prus]

Nick Roberts wrote:

> 2006-03-12  Nick Roberts  <nickrob@snap.net.nz>
> 
> * mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print
> instead of print_variable_value so that type doesn't get printed
> with value.

This patch is much more important that value formatting, in fact. Without
it, if there's local reference variable that's no initialized, we get this
output from gdb:

   (gdb) -stack-list-locals --all-values 
   Cannot access memory at address 0x1
   ^error,msg="Cannot access memory at address 0x1"

Essentially, I can't see any local variables. This patch fixes this too,
because, I believe, common_val_print does check for non-dereferencable
values. Changelogs say common_val_print was specifically added for this
purpose.

- Volodya

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Mar 17, 2006 at 07:07:17PM +0300, Vladimir Prus wrote:
> Nick Roberts wrote:
> 
> > 2006-03-12  Nick Roberts  <nickrob@snap.net.nz>
> > 
> > * mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print
> > instead of print_variable_value so that type doesn't get printed
> > with value.
> 
> This patch is much more important that value formatting, in fact. Without
> it, if there's local reference variable that's no initialized, we get this
> output from gdb:
> 
>    (gdb) -stack-list-locals --all-values 
>    Cannot access memory at address 0x1
>    ^error,msg="Cannot access memory at address 0x1"
> 
> Essentially, I can't see any local variables. This patch fixes this too,
> because, I believe, common_val_print does check for non-dereferencable
> values. Changelogs say common_val_print was specifically added for this
> purpose.

Did you try this?  I don't think it will: common_val_print was added
for the optimized-out case, not for the memory-error case, which should
be handled somewhere else.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Fri, Mar 17, 2006 at 07:07:17PM +0300, Vladimir Prus wrote:
>> Nick Roberts wrote:
>> 
>> > 2006-03-12  Nick Roberts  <nickrob@snap.net.nz>
>> > 
>> > * mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print
>> > instead of print_variable_value so that type doesn't get printed
>> > with value.
>> 
>> This patch is much more important that value formatting, in fact. Without
>> it, if there's local reference variable that's no initialized, we get
>> this output from gdb:
>> 
>>    (gdb) -stack-list-locals --all-values
>>    Cannot access memory at address 0x1
>>    ^error,msg="Cannot access memory at address 0x1"
>> 
>> Essentially, I can't see any local variables. This patch fixes this too,
>> because, I believe, common_val_print does check for non-dereferencable
>> values. Changelogs say common_val_print was specifically added for this
>> purpose.
> 
> Did you try this?  

Yes, I did. I got the above error without the patch, with CVS HEAD state. I
got the list of local variables, on the same testcase, with CVS HEAD +
patch.

> I don't think it will: common_val_print was added 
> for the optimized-out case, not for the memory-error case, which should
> be handled somewhere else.

I don't know why, but this patch fixes the memory error too.

- Volodya

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Mon, Mar 20, 2006 at 09:40:49AM +0300, Vladimir Prus wrote:
> > On Fri, Mar 17, 2006 at 07:07:17PM +0300, Vladimir Prus wrote:
> >> Nick Roberts wrote:
> >> 
> >> > 2006-03-12  Nick Roberts  <nickrob@snap.net.nz>
> >> > 
> >> > * mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print
> >> > instead of print_variable_value so that type doesn't get printed
> >> > with value.
> >> 
> >> This patch is much more important that value formatting, in fact. Without
> >> it, if there's local reference variable that's no initialized, we get
> >> this output from gdb:
> >> 
> >>    (gdb) -stack-list-locals --all-values
> >>    Cannot access memory at address 0x1
> >>    ^error,msg="Cannot access memory at address 0x1"
> >> 
> >> Essentially, I can't see any local variables. This patch fixes this too,
> >> because, I believe, common_val_print does check for non-dereferencable
> >> values. Changelogs say common_val_print was specifically added for this
> >> purpose.
> > 
> > Did you try this?  
> 
> Yes, I did. I got the above error without the patch, with CVS HEAD state. I
> got the list of local variables, on the same testcase, with CVS HEAD +
> patch.

OK, I checked this out.  Before, if all the variables are initialized:

^done,locals=[{name="baz",value="2"},{name="blaz2",value="(int &) @0x5009c8: 1"},
{name="blaz4",value="(int &) @0x5009c8: 1"},
{name="blaz",value="(int &) @0x5009c8: 1"},
{name="blaz3",value="(int &) @0x5009c8: 1"},
{name="blaz5",value="(int &) @0x5009c8: 1"}]

If they aren't:

&"Cannot access memory at address 0x0\n"
^error,msg="Cannot access memory at address 0x0"

After:

^done,locals=[{name="baz",value="10922"},{name="blaz2",value="@0x2aaaaabc1ca0"},
{name="blaz4",value="@0x4005e0"},{name="blaz",value="@0x0"},
{name="blaz3",value="@0x40041b"},{name="blaz5",value="@0x400578"}]

Now we are showing only the reference, not the target.  I would have
expected the target value.

Looking at Eclipse:
  cdi/org/eclipse/cdt/debug/mi/core/cdi/model/type/IntegralValue.java

                // Coming from a reference
                if (valueString.startsWith("@")) { //$NON-NLS-1$
                        valueString = valueString.substring(1);
                        int colon = valueString.indexOf(':');
                        if (colon != -1) {
                                valueString = valueString.substring(colon + 1); 
                        }
                } else {

It wants to show the value in its variables window, not the reference.
So this patch would break it.

So, should we change common_val_print, do you think?

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Vladimir Prus]

Daniel Jacobowitz wrote:

> OK, I checked this out.  Before, if all the variables are initialized:
> 
> ^done,locals=[{name="baz",value="2"},{name="blaz2",value="(int &)
> @0x5009c8: 1"},
> {name="blaz4",value="(int &) @0x5009c8: 1"},
> {name="blaz",value="(int &) @0x5009c8: 1"},
> {name="blaz3",value="(int &) @0x5009c8: 1"},
> {name="blaz5",value="(int &) @0x5009c8: 1"}]
> 
> If they aren't:
> 
> &"Cannot access memory at address 0x0\n"
> ^error,msg="Cannot access memory at address 0x0"
> 
> After:
> 
> ^done,locals=[{name="baz",value="10922"}
{name="blaz2",value="@0x2aaaaabc1ca0"},
> {name="blaz4",value="@0x4005e0"},{name="blaz",value="@0x0"},
> {name="blaz3",value="@0x40041b"},{name="blaz5",value="@0x400578"}]
> 
> Now we are showing only the reference, not the target.  I would have
> expected the target value.
> 
> Looking at Eclipse:
>   cdi/org/eclipse/cdt/debug/mi/core/cdi/model/type/IntegralValue.java
> 
>                 // Coming from a reference
>                 if (valueString.startsWith("@")) { //$NON-NLS-1$
>                         valueString = valueString.substring(1);
>                         int colon = valueString.indexOf(':');
>                         if (colon != -1) {
>                                 valueString = valueString.substring(colon
>                                 + 1);
>                         }

So, Eclipse is manually parsing the "value" string? I pretty sure I've heard
either Bob, or Eli say this is not good idea. In fact, I suspect I heard
both of them say this.

>                 } else {
> 
> It wants to show the value in its variables window, not the reference.
> So this patch would break it.
> 
> So, should we change common_val_print, do you think?

Short-term, this might be a solution. But note again that depending on
textual "value" field is bad idea in any case.

Long-term the right solution is:

  - Port the Apple change that allows to get variable objects for all
    local variables in one command.
  - Port Apple change that add 'typecode' field to variable objects
  - Add command/variable object format to deference references
  - Teach Eclipse that for variable object with "reference" typecode,
    it should dereference variable object, or whatever is appropriate.

This could be a long process, though. 


- Volodya

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Mar 24, 2006 at 11:30:54AM +0300, Vladimir Prus wrote:
> > Looking at Eclipse:
> >   cdi/org/eclipse/cdt/debug/mi/core/cdi/model/type/IntegralValue.java
> > 
> >                 // Coming from a reference
> >                 if (valueString.startsWith("@")) { //$NON-NLS-1$
> >                         valueString = valueString.substring(1);
> >                         int colon = valueString.indexOf(':');
> >                         if (colon != -1) {
> >                                 valueString = valueString.substring(colon
> >                                 + 1);
> >                         }
> 
> So, Eclipse is manually parsing the "value" string? I pretty sure I've heard
> either Bob, or Eli say this is not good idea. In fact, I suspect I heard
> both of them say this.

Heck, I've said it too.  However, in the real world, we need to be a
bit careful of frontends which do it.  I strongly discourage new
frontends doing so, but I also try not to break existing frontends
which do - this is an extension of "be liberal in what you accept,
but conservative in what you generate".

> >                 } else {
> > 
> > It wants to show the value in its variables window, not the reference.
> > So this patch would break it.
> > 
> > So, should we change common_val_print, do you think?
> 
> Short-term, this might be a solution. But note again that depending on
> textual "value" field is bad idea in any case.

That's not actually what I meant - I'm not thinking of MI here. 
common_val_print gets called from a number of places:

- varobj c_value_of_variable, used by Insight and MI
  (-var-list-children, -var-evaluate-expression, -var-assign,
   -var-update).

- print_frame_args, where it is used to deliberately print
  only the address of a reference.  I'm not entirely sure why.

- Languages, to implement value_print - not relevant right now.

> Long-term the right solution is:
> 
>   - Port the Apple change that allows to get variable objects for all
>     local variables in one command.

This sounds sensible.

>   - Port Apple change that add 'typecode' field to variable objects

I understand why they did this, but should we really be exposing GDB's
internal type system this way?  I'd want to see what it gets used for,
and probably define it independently of the existing type codes.

>   - Add command/variable object format to deference references
>   - Teach Eclipse that for variable object with "reference" typecode,
>     it should dereference variable object, or whatever is appropriate.
> 
> This could be a long process, though. 

Yes indeed.  Hmm.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Vladimir Prus]

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

Daniel Jacobowitz wrote:

>> >                 } else {
>> > 
>> > It wants to show the value in its variables window, not the reference.
>> > So this patch would break it.
>> > 
>> > So, should we change common_val_print, do you think?
>> 
>> Short-term, this might be a solution. But note again that depending on
>> textual "value" field is bad idea in any case.
> 
> That's not actually what I meant - I'm not thinking of MI here.
> common_val_print gets called from a number of places:
> 
> - varobj c_value_of_variable, used by Insight and MI
>   (-var-list-children, -var-evaluate-expression, -var-assign,
>    -var-update).
> 
> - print_frame_args, where it is used to deliberately print
>   only the address of a reference.  I'm not entirely sure why.
> 
> - Languages, to implement value_print - not relevant right now.

It appears that 'common_val_print' has 'deref_ref' parameter which can be
used to get back the old behaviour. However, then we'll again get no output
if there's any undereferencable reference.

I attach a patch that addresses this issue -- now, undereferencable
references don't throw. For dereferencable references the value is printed
after ":" as it is now.

Changelog:

2006-04-04 Vladimir Prus <ghost@cs.msu.su>

    * c-valprint.c (c_val_print): Explicitly check if a reference
      is dereferencable.
    * valops.c (value_at_maybe): New function
    * value.h (value_at_maybe): Export.
    * mi/mi-cmd-stack.c (list_args_or_locals): Use 'common_val_print',
     instead of 'print_value_value'. Remove code duplication.

Patch is attached.

- Volodya

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: MI_stack_list_locals_references.diff --]
[-- Type: text/x-diff; name="MI_stack_list_locals_references.diff", Size: 4582 bytes --]

Index: c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
retrieving revision 1.39
diff -u -p -r1.39 c-valprint.c
--- c-valprint.c	18 Jan 2006 21:24:19 -0000	1.39
+++ c-valprint.c	6 Apr 2006 08:28:55 -0000
@@ -277,13 +277,16 @@ c_val_print (struct type *type, const gd
 	{
 	  if (TYPE_CODE (elttype) != TYPE_CODE_UNDEF)
 	    {
-	      struct value *deref_val =
-	      value_at
-	      (TYPE_TARGET_TYPE (type),
-	       unpack_pointer (lookup_pointer_type (builtin_type_void),
-			       valaddr + embedded_offset));
-	      common_val_print (deref_val, stream, format, deref_ref,
-				recurse, pretty);
+              CORE_ADDR addr = unpack_pointer (
+                  lookup_pointer_type (builtin_type_void),
+                  valaddr + embedded_offset);
+              struct value *deref_val = value_at_maybe(TYPE_TARGET_TYPE(type), 
+                                                       addr);
+              if (deref_val)
+                common_val_print (deref_val, stream, format, deref_ref,
+                                  recurse, pretty);
+              else
+                fputs_filtered("memory not accessible", stream);
 	    }
 	  else
 	    fputs_filtered ("???", stream);
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.163
diff -u -p -r1.163 valops.c
--- valops.c	17 Dec 2005 22:34:03 -0000	1.163
+++ valops.c	6 Apr 2006 08:28:55 -0000
@@ -472,6 +472,36 @@ value_at (struct type *type, CORE_ADDR a
   return val;
 }
 
+
+/* Same as 'value_at', but returns NULL when memory can't be read
+   instead of throwing.
+*/
+struct value* 
+value_at_maybe (struct type *type, CORE_ADDR addr)
+{
+  struct value *val;
+  int status;
+
+  if (TYPE_CODE (check_typedef (type)) == TYPE_CODE_VOID)
+    error (_("Attempt to dereference a generic pointer."));
+
+
+  val = allocate_value (type);
+  status = target_read_memory (addr, value_contents_all_raw(val), 
+                               TYPE_LENGTH (type));
+  if (status == 0)
+    {      
+      VALUE_LVAL (val) = lval_memory;
+      VALUE_ADDRESS (val) = addr;
+      return val;
+    }
+  else
+    {
+      return 0;  
+    }
+}
+
+
 /* Return a lazy value with type TYPE located at ADDR (cf. value_at).  */
 
 struct value *
Index: value.h
===================================================================
RCS file: /cvs/src/src/gdb/value.h,v
retrieving revision 1.90
diff -u -p -r1.90 value.h
--- value.h	1 Feb 2006 23:14:10 -0000	1.90
+++ value.h	6 Apr 2006 08:28:56 -0000
@@ -277,6 +277,8 @@ extern struct value *value_from_string (
 
 extern struct value *value_at (struct type *type, CORE_ADDR addr);
 extern struct value *value_at_lazy (struct type *type, CORE_ADDR addr);
+extern struct value *value_at_maybe (struct type *type, CORE_ADDR addr);
+
 
 extern struct value *value_from_register (struct type *type, int regnum,
 					  struct frame_info *frame);
Index: mi/mi-cmd-stack.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-stack.c,v
retrieving revision 1.29
diff -u -p -r1.29 mi-cmd-stack.c
--- mi/mi-cmd-stack.c	23 Dec 2005 18:57:46 -0000	1.29
+++ mi/mi-cmd-stack.c	6 Apr 2006 08:28:56 -0000
@@ -278,6 +278,8 @@ list_args_or_locals (int locals, int val
 	    {
 	      struct cleanup *cleanup_tuple = NULL;
 	      struct symbol *sym2;
+	      struct value *val;
+              int print_it = 0;
 	      if (values != PRINT_NO_VALUES)
 		cleanup_tuple =
 		  make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
@@ -300,17 +302,24 @@ list_args_or_locals (int locals, int val
 		      && TYPE_CODE (type) != TYPE_CODE_STRUCT
 		      && TYPE_CODE (type) != TYPE_CODE_UNION)
 		    {
-		      print_variable_value (sym2, fi, stb->stream);
-		      ui_out_field_stream (uiout, "value", stb);
+                      print_it = 1;
 		    }
 		  do_cleanups (cleanup_tuple);
 		  break;
 		case PRINT_ALL_VALUES:
-		  print_variable_value (sym2, fi, stb->stream);
-		  ui_out_field_stream (uiout, "value", stb);
-		  do_cleanups (cleanup_tuple);
+                    print_it = 1;
 		  break;
 		}
+
+              if (print_it)
+                {
+                  val = read_var_value (sym2, fi);
+		  common_val_print
+		    (val, stb->stream, 0, 1 /*deref refs*/, 2, Val_no_prettyprint);
+		  ui_out_field_stream (uiout, "value", stb);
+		  do_cleanups (cleanup_tuple);                  
+                }
+
 	    }
 	}
       if (BLOCK_FUNCTION (block))

Re: MI: type prefixes for values

[Vladimir Prus]

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


Any comments on the patch I've send two weeks ago? Note that I'm not longer
interested in this patch myself, since I no longer use "--stack-list-frames
--all-values" in KDevelop, but I believe the patch affects the MI support
in Emacs that Nick is working on.

- Volodya

>> - print_frame_args, where it is used to deliberately print
>>   only the address of a reference.  I'm not entirely sure why.
>> 
>> - Languages, to implement value_print - not relevant right now.
> 
> It appears that 'common_val_print' has 'deref_ref' parameter which can be
> used to get back the old behaviour. However, then we'll again get no
> output if there's any undereferencable reference.
> 
> I attach a patch that addresses this issue -- now, undereferencable
> references don't throw. For dereferencable references the value is printed
> after ":" as it is now.
> 
> Changelog:
> 
> 2006-04-04 Vladimir Prus <ghost@cs.msu.su>
> 
>     * c-valprint.c (c_val_print): Explicitly check if a reference
>       is dereferencable.
>     * valops.c (value_at_maybe): New function
>     * value.h (value_at_maybe): Export.
>     * mi/mi-cmd-stack.c (list_args_or_locals): Use 'common_val_print',
>      instead of 'print_value_value'. Remove code duplication.
> 
> Patch is attached.
> 
> - Volodya

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: MI_stack_list_locals_references.diff --]
[-- Type: text/x-diff; name="MI_stack_list_locals_references.diff", Size: 4582 bytes --]

Index: c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
retrieving revision 1.39
diff -u -p -r1.39 c-valprint.c
--- c-valprint.c	18 Jan 2006 21:24:19 -0000	1.39
+++ c-valprint.c	6 Apr 2006 08:28:55 -0000
@@ -277,13 +277,16 @@ c_val_print (struct type *type, const gd
 	{
 	  if (TYPE_CODE (elttype) != TYPE_CODE_UNDEF)
 	    {
-	      struct value *deref_val =
-	      value_at
-	      (TYPE_TARGET_TYPE (type),
-	       unpack_pointer (lookup_pointer_type (builtin_type_void),
-			       valaddr + embedded_offset));
-	      common_val_print (deref_val, stream, format, deref_ref,
-				recurse, pretty);
+              CORE_ADDR addr = unpack_pointer (
+                  lookup_pointer_type (builtin_type_void),
+                  valaddr + embedded_offset);
+              struct value *deref_val = value_at_maybe(TYPE_TARGET_TYPE(type), 
+                                                       addr);
+              if (deref_val)
+                common_val_print (deref_val, stream, format, deref_ref,
+                                  recurse, pretty);
+              else
+                fputs_filtered("memory not accessible", stream);
 	    }
 	  else
 	    fputs_filtered ("???", stream);
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.163
diff -u -p -r1.163 valops.c
--- valops.c	17 Dec 2005 22:34:03 -0000	1.163
+++ valops.c	6 Apr 2006 08:28:55 -0000
@@ -472,6 +472,36 @@ value_at (struct type *type, CORE_ADDR a
   return val;
 }
 
+
+/* Same as 'value_at', but returns NULL when memory can't be read
+   instead of throwing.
+*/
+struct value* 
+value_at_maybe (struct type *type, CORE_ADDR addr)
+{
+  struct value *val;
+  int status;
+
+  if (TYPE_CODE (check_typedef (type)) == TYPE_CODE_VOID)
+    error (_("Attempt to dereference a generic pointer."));
+
+
+  val = allocate_value (type);
+  status = target_read_memory (addr, value_contents_all_raw(val), 
+                               TYPE_LENGTH (type));
+  if (status == 0)
+    {      
+      VALUE_LVAL (val) = lval_memory;
+      VALUE_ADDRESS (val) = addr;
+      return val;
+    }
+  else
+    {
+      return 0;  
+    }
+}
+
+
 /* Return a lazy value with type TYPE located at ADDR (cf. value_at).  */
 
 struct value *
Index: value.h
===================================================================
RCS file: /cvs/src/src/gdb/value.h,v
retrieving revision 1.90
diff -u -p -r1.90 value.h
--- value.h	1 Feb 2006 23:14:10 -0000	1.90
+++ value.h	6 Apr 2006 08:28:56 -0000
@@ -277,6 +277,8 @@ extern struct value *value_from_string (
 
 extern struct value *value_at (struct type *type, CORE_ADDR addr);
 extern struct value *value_at_lazy (struct type *type, CORE_ADDR addr);
+extern struct value *value_at_maybe (struct type *type, CORE_ADDR addr);
+
 
 extern struct value *value_from_register (struct type *type, int regnum,
 					  struct frame_info *frame);
Index: mi/mi-cmd-stack.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-stack.c,v
retrieving revision 1.29
diff -u -p -r1.29 mi-cmd-stack.c
--- mi/mi-cmd-stack.c	23 Dec 2005 18:57:46 -0000	1.29
+++ mi/mi-cmd-stack.c	6 Apr 2006 08:28:56 -0000
@@ -278,6 +278,8 @@ list_args_or_locals (int locals, int val
 	    {
 	      struct cleanup *cleanup_tuple = NULL;
 	      struct symbol *sym2;
+	      struct value *val;
+              int print_it = 0;
 	      if (values != PRINT_NO_VALUES)
 		cleanup_tuple =
 		  make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
@@ -300,17 +302,24 @@ list_args_or_locals (int locals, int val
 		      && TYPE_CODE (type) != TYPE_CODE_STRUCT
 		      && TYPE_CODE (type) != TYPE_CODE_UNION)
 		    {
-		      print_variable_value (sym2, fi, stb->stream);
-		      ui_out_field_stream (uiout, "value", stb);
+                      print_it = 1;
 		    }
 		  do_cleanups (cleanup_tuple);
 		  break;
 		case PRINT_ALL_VALUES:
-		  print_variable_value (sym2, fi, stb->stream);
-		  ui_out_field_stream (uiout, "value", stb);
-		  do_cleanups (cleanup_tuple);
+                    print_it = 1;
 		  break;
 		}
+
+              if (print_it)
+                {
+                  val = read_var_value (sym2, fi);
+		  common_val_print
+		    (val, stb->stream, 0, 1 /*deref refs*/, 2, Val_no_prettyprint);
+		  ui_out_field_stream (uiout, "value", stb);
+		  do_cleanups (cleanup_tuple);                  
+                }
+
 	    }
 	}
       if (BLOCK_FUNCTION (block))

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Apr 28, 2006 at 10:32:34AM +0400, Vladimir Prus wrote:
> 
> Any comments on the patch I've send two weeks ago? Note that I'm not longer
> interested in this patch myself, since I no longer use "--stack-list-frames
> --all-values" in KDevelop, but I believe the patch affects the MI support
> in Emacs that Nick is working on.

After thinking about it for a bit, let's not do it this way.  I think
we could put a catch at the right place and make all possible memory
errors come out consistently - I'm thinking something like

  volatile struct gdb_exception except;
  int ret = 0;

  ...

  TRY_CATCH (except, RETURN_MASK_ERROR)
    {
      ret = val_print (...);
    }
  if (except.reason < 0)
    fprintf_filtered (stream, _("<error reading variable>"));

  return ret;

This would probably either require additional changes, to use
common_val_print and value_field et cetera in more places, or
else have to be placed in val_print directly, around the call to
LA_VAL_PRINT.  The latter is easier.

Here's a patch; before it I get:

(gdb) i locals 
ref = (int &) @0x2ae2e8dc0392: 1287883081
ref3 = (int &) @0x2ae2e90bc7a0: -385103520
ref5 = (int &) @0x0: Cannot access memory at address 0x0

After:

(gdb) i locals 
ref = (int &) @0x2ac1ec165392: 1287883081
ref3 = (int &) @0x2ac1ec4617a0: -330950304
ref5 = (int &) @0x0: <error reading variable>
ref7 = (int &) @0x40041b: 147096392
ref9 = (int &) @0x400588: 352685384
ref2 = (int &) @0x2ac1ec4630c0: -330969896
ref4 = (int &) @0x2ac1ec460fe0: -330952736
ref6 = (int &) @0x2ac1ec270ca0: 0
ref8 = (int &) @0x4005f0: 610568524

Similarly:

(gdb) interpreter-exec mi "-stack-list-locals 1"
^done,locals=[{name="ref",value="(int &) @0x2ba30c30d392:
1287883081"},{name="ref3",value="(int &) @0x2ba30c6097a0:
207657312"},{name="ref5",value="(int &) @0x0: <error reading
variable>"},{name="ref7",value="(int &) @0x40041b:
147096392"},{name="ref9",value="(int &) @0x400588:
352685384"},{name="ref2",value="(int &) @0x2ba30c60b0c0:
207637720"},{name="ref4",value="(int &) @0x2ba30c608fe0:
207654880"},{name="ref6",value="(int &) @0x2ba30c418ca0:
0"},{name="ref8",value="(int &) @0x4005f0: 610568524"}]

We already print out various <angle brackets> messages for error
conditions; I think adding a new one is fine.  How about you?

This patch doesn't touch the issue of type prefixes, leaving that to
deal with separately.


-- 
Daniel Jacobowitz
CodeSourcery

2006-05-05  Daniel Jacobowitz  <dan@codesourcery.com>

	* valprint.c: Include "exceptions.h".
	(val_print): If something goes wrong while printing, supply an
	error message.

Index: valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/valprint.c,v
retrieving revision 1.59
diff -u -p -r1.59 valprint.c
--- valprint.c	18 Jan 2006 21:24:19 -0000	1.59
+++ valprint.c	5 May 2006 19:23:53 -0000
@@ -34,6 +34,7 @@
 #include "valprint.h"
 #include "floatformat.h"
 #include "doublest.h"
+#include "exceptions.h"
 
 #include <errno.h>
 
@@ -205,6 +206,9 @@ val_print (struct type *type, const gdb_
 	   CORE_ADDR address, struct ui_file *stream, int format,
 	   int deref_ref, int recurse, enum val_prettyprint pretty)
 {
+  volatile struct gdb_exception except;
+  int ret = 0;
+
   struct type *real_type = check_typedef (type);
   if (pretty == Val_pretty_default)
     {
@@ -224,8 +228,15 @@ val_print (struct type *type, const gdb_
       return (0);
     }
 
-  return (LA_VAL_PRINT (type, valaddr, embedded_offset, address,
-			stream, format, deref_ref, recurse, pretty));
+  TRY_CATCH (except, RETURN_MASK_ERROR)
+    {
+      ret = LA_VAL_PRINT (type, valaddr, embedded_offset, address,
+			  stream, format, deref_ref, recurse, pretty);
+    }
+  if (except.reason < 0)
+    fprintf_filtered (stream, _("<error reading variable>"));
+
+  return ret;
 }
 
 /* Check whether the value VAL is printable.  Return 1 if it is;
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.811
diff -u -p -r1.811 Makefile.in
--- Makefile.in	23 Apr 2006 14:15:01 -0000	1.811
+++ Makefile.in	5 May 2006 19:24:26 -0000
@@ -2773,7 +2773,8 @@ valops.o: valops.c $(defs_h) $(symtab_h)
 	$(cp_support_h) $(observer_h)
 valprint.o: valprint.c $(defs_h) $(gdb_string_h) $(symtab_h) $(gdbtypes_h) \
 	$(value_h) $(gdbcore_h) $(gdbcmd_h) $(target_h) $(language_h) \
-	$(annotate_h) $(valprint_h) $(floatformat_h) $(doublest_h)
+	$(annotate_h) $(valprint_h) $(floatformat_h) $(doublest_h) \
+	$(exceptions_h)
 value.o: value.c $(defs_h) $(gdb_string_h) $(symtab_h) $(gdbtypes_h) \
 	$(value_h) $(gdbcore_h) $(command_h) $(gdbcmd_h) $(target_h) \
 	$(language_h) $(scm_lang_h) $(demangle_h) $(doublest_h) \

Re: MI: type prefixes for values

[Nick Roberts]

> > Any comments on the patch I've send two weeks ago? Note that I'm not longer
> > interested in this patch myself, since I no longer use "--stack-list-frames
> > --all-values" in KDevelop, but I believe the patch affects the MI support
> > in Emacs that Nick is working on.

Sorry to be pedantic again, but this relates to -stack-list-locals
(and -stack-list-args), not -stack-list-frames.

> Here's a patch; before it I get:
> 
> (gdb) i locals 
> ref = (int &) @0x2ae2e8dc0392: 1287883081
> ref3 = (int &) @0x2ae2e90bc7a0: -385103520
> ref5 = (int &) @0x0: Cannot access memory at address 0x0
> 
> After:
> 
> (gdb) i locals 
> ref = (int &) @0x2ac1ec165392: 1287883081
> ref3 = (int &) @0x2ac1ec4617a0: -330950304
> ref5 = (int &) @0x0: <error reading variable>
> ref7 = (int &) @0x40041b: 147096392
> ref9 = (int &) @0x400588: 352685384
> ref2 = (int &) @0x2ac1ec4630c0: -330969896
> ref4 = (int &) @0x2ac1ec460fe0: -330952736
> ref6 = (int &) @0x2ac1ec270ca0: 0
> ref8 = (int &) @0x4005f0: 610568524

> Similarly:

> (gdb) interpreter-exec mi "-stack-list-locals 1"
> ^done,locals=[{name="ref",value="(int &) @0x2ba30c30d392:
> 1287883081"},{name="ref3",value="(int &) @0x2ba30c6097a0:
> 207657312"},{name="ref5",value="(int &) @0x0: <error reading
> variable>"},{name="ref7",value="(int &) @0x40041b:
> 147096392"},{name="ref9",value="(int &) @0x400588:
> 352685384"},{name="ref2",value="(int &) @0x2ba30c60b0c0:
> 207637720"},{name="ref4",value="(int &) @0x2ba30c608fe0:
> 207654880"},{name="ref6",value="(int &) @0x2ba30c418ca0:
> 0"},{name="ref8",value="(int &) @0x4005f0: 610568524"}]

> We already print out various <angle brackets> messages for error
> conditions; I think adding a new one is fine.  How about you?

It looks like you're catching the error lower down (higher up?)  which allows
any other values to be printed.  Right?  I like this.

> This patch doesn't touch the issue of type prefixes, leaving that to
> deal with separately.

If I'm reading this right, I have since realised that my patch to use
common_val_print was no good because it only prints address and not values for
things like references


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: type prefixes for values

[Daniel Jacobowitz]

> 2006-05-05  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	* valprint.c: Include "exceptions.h".
> 	(val_print): If something goes wrong while printing, supply an
> 	error message.

I have committed this.

On Sat, May 06, 2006 at 09:58:38PM +1200, Nick Roberts wrote:
> It looks like you're catching the error lower down (higher up?)  which allows
> any other values to be printed.  Right?  I like this.

Exactly right - higher up vs lower down is a bit tricky since all of
this stuff is recursive, but probably higher up the call chain.

> > This patch doesn't touch the issue of type prefixes, leaving that to
> > deal with separately.
> 
> If I'm reading this right, I have since realised that my patch to use
> common_val_print was no good because it only prints address and not values for
> things like references

Vladimir noticed that there's a deref_ref argument to common_val_print;
you passed zero, but if you pass one instead, it ought to do the right
thing.

Would you like to try the patch again with that change?

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Nick Roberts]

 > > > This patch doesn't touch the issue of type prefixes, leaving that to
 > > > deal with separately.
 > > 
 > > If I'm reading this right, I have since realised that my patch to use
 > > common_val_print was no good because it only prints address and not values
 > > for things like references
 > 
 > Vladimir noticed that there's a deref_ref argument to common_val_print;
 > you passed zero, but if you pass one instead, it ought to do the right
 > thing.
 > 
 > Would you like to try the patch again with that change?

Yes, it works as you suggest.  The testsuite is unchanged (-stack-list-locals
only prints the type for integers and there are no tests for -stack-list-args).

It might be a good idea to create a test for a reference variable.  Previously
I suggested that a test for your change to val_print could be done in
mi-var-display.exp or mi-var-cmd.exp, but it needn't be as a variable object
and it could presumably be combined with this test in mi-stack.exp.


-- 
Nick                                           http://www.inet.net.nz/~nickrob



2006-05-17  Nick Roberts  <nickrob@snap.net.nz>

	* mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print
	instead of print_variable_value so that type doesn't get printed
	with value.


*** mi-cmd-stack.c	05 Jan 2006 10:56:18 +1300	1.29
--- mi-cmd-stack.c	17 May 2006 15:00:29 +1200	
*************** list_args_or_locals (int locals, int val
*** 278,283 ****
--- 278,284 ----
  	    {
  	      struct cleanup *cleanup_tuple = NULL;
  	      struct symbol *sym2;
+ 	      struct value *val;
  	      if (values != PRINT_NO_VALUES)
  		cleanup_tuple =
  		  make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
*************** list_args_or_locals (int locals, int val
*** 300,312 ****
  		      && TYPE_CODE (type) != TYPE_CODE_STRUCT
  		      && TYPE_CODE (type) != TYPE_CODE_UNION)
  		    {
! 		      print_variable_value (sym2, fi, stb->stream);
  		      ui_out_field_stream (uiout, "value", stb);
  		    }
  		  do_cleanups (cleanup_tuple);
  		  break;
  		case PRINT_ALL_VALUES:
! 		  print_variable_value (sym2, fi, stb->stream);
  		  ui_out_field_stream (uiout, "value", stb);
  		  do_cleanups (cleanup_tuple);
  		  break;
--- 301,317 ----
  		      && TYPE_CODE (type) != TYPE_CODE_STRUCT
  		      && TYPE_CODE (type) != TYPE_CODE_UNION)
  		    {
! 		      val = read_var_value (sym2, fi);
! 		      common_val_print
! 			(val, stb->stream, 0, 1, 2, Val_no_prettyprint);
  		      ui_out_field_stream (uiout, "value", stb);
  		    }
  		  do_cleanups (cleanup_tuple);
  		  break;
  		case PRINT_ALL_VALUES:
! 		  val = read_var_value (sym2, fi);
! 		  common_val_print
! 		    (val, stb->stream, 0, 1, 2, Val_no_prettyprint);
  		  ui_out_field_stream (uiout, "value", stb);
  		  do_cleanups (cleanup_tuple);
  		  break;

Re: MI: type prefixes for values [PATCH]

[Nick Roberts]

On Mon, 15 May 2006 12:53:54 -0400 at Daniel Jacobowitz writes:
 > > > This patch doesn't touch the issue of type prefixes, leaving that to
 > > > deal with separately.
 > > 
 > > If I'm reading this right, I have since realised that my patch to use
 > > common_val_print was no good because it only prints address and not values
 > > for things like references
 > 
 > Vladimir noticed that there's a deref_ref argument to common_val_print;
 > you passed zero, but if you pass one instead, it ought to do the right
 > thing.
 > 
 > Would you like to try the patch again with that change?

Here's a patch which got a bit lost in the mists of time.  No regressions.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2007-02-03  Nick Roberts  <nickrob@snap.net.nz>

	* mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print
	instead of print_variable_value to print values.


*** mi-cmd-stack.c	10 Jan 2007 11:56:57 +1300	1.32
--- mi-cmd-stack.c	03 Feb 2007 18:25:42 +1300	
*************** list_args_or_locals (int locals, int val
*** 275,281 ****
  	    {
  	      struct cleanup *cleanup_tuple = NULL;
  	      struct symbol *sym2;
! 	      if (values != PRINT_NO_VALUES)
  		cleanup_tuple =
  		  make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
  	      ui_out_field_string (uiout, "name", SYMBOL_PRINT_NAME (sym));
--- 275,282 ----
  	    {
  	      struct cleanup *cleanup_tuple = NULL;
  	      struct symbol *sym2;
!  	      struct value *val;
!  	      if (values != PRINT_NO_VALUES)
  		cleanup_tuple =
  		  make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
  	      ui_out_field_string (uiout, "name", SYMBOL_PRINT_NAME (sym));
*************** list_args_or_locals (int locals, int val
*** 297,309 ****
  		      && TYPE_CODE (type) != TYPE_CODE_STRUCT
  		      && TYPE_CODE (type) != TYPE_CODE_UNION)
  		    {
! 		      print_variable_value (sym2, fi, stb->stream);
  		      ui_out_field_stream (uiout, "value", stb);
  		    }
  		  do_cleanups (cleanup_tuple);
  		  break;
  		case PRINT_ALL_VALUES:
! 		  print_variable_value (sym2, fi, stb->stream);
  		  ui_out_field_stream (uiout, "value", stb);
  		  do_cleanups (cleanup_tuple);
  		  break;
--- 298,314 ----
  		      && TYPE_CODE (type) != TYPE_CODE_STRUCT
  		      && TYPE_CODE (type) != TYPE_CODE_UNION)
  		    {
!  		      val = read_var_value (sym2, fi);
!  		      common_val_print
!  			(val, stb->stream, 0, 1, 0, Val_no_prettyprint);
  		      ui_out_field_stream (uiout, "value", stb);
  		    }
  		  do_cleanups (cleanup_tuple);
  		  break;
  		case PRINT_ALL_VALUES:
!  		  val = read_var_value (sym2, fi);
!  		  common_val_print
!  		    (val, stb->stream, 0, 1, 0, Val_no_prettyprint);
  		  ui_out_field_stream (uiout, "value", stb);
  		  do_cleanups (cleanup_tuple);
  		  break;

Re: MI: type prefixes for values [PATCH]

[Daniel Jacobowitz]

On Sat, Feb 03, 2007 at 06:31:02PM +1300, Nick Roberts wrote:
> Here's a patch which got a bit lost in the mists of time.  No regressions.

> 2007-02-03  Nick Roberts  <nickrob@snap.net.nz>
> 
> 	* mi/mi-cmd-stack.c (list_args_or_locals): Use common_val_print
> 	instead of print_variable_value to print values.

Sorry about losing this.  The patch is OK; if you have a chance to add
a test for printing references, that would be nice too.

> !  	      struct value *val;
> !  	      if (values != PRINT_NO_VALUES)

Looks like you added a space before the tab on that line?  Please fix
before commit.  Thanks.


-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values [PATCH]

[Nick Roberts]

 > Sorry about losing this.  The patch is OK; if you have a chance to add
 > a test for printing references, that would be nice too.

It might have been me who didn't follow up.  I'll submit a test .

 > > !  	      struct value *val;
 > > !  	      if (values != PRINT_NO_VALUES)
 > 
 > Looks like you added a space before the tab on that line?  Please fix
 > before commit.  Thanks.

Committed.  I've tried to remove the space(s).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Sun, Mar 12, 2006 at 08:56:45PM +1300, Nick Roberts wrote:
> Here's a patch that doesn't print the type with the value for 
> -stack-list-arguments and -stack-list-list-locals (they both use
> list_args_or_locals).

This seems plausible to me.  I checked what the change actually
does: it goes through LA_VAL_PRINT instead of LA_VALUE_PRINT.  For
C, the differences between the two are (A) the types of pointers
and references are printed, and (B) "set print object" is honored.
We don't want (A), and (B) is pretty rusty now since we don't test
it and it doesn't get used much, so I'm not worried about it.

Are there any compatibility concerns, i.e. should we make this change
for mi3 only?  Could some frontend rely on these outputs?  I don't
think Eclipse does - it looks like it has some substantial code
to skip them, though, so at least it is aware of them.


-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Nick Roberts]

 > Are there any compatibility concerns, i.e. should we make this change
 > for mi3 only?  Could some frontend rely on these outputs?  I don't
 > think Eclipse does - it looks like it has some substantial code
 > to skip them, though, so at least it is aware of them.

Unlike Volodya's change, its not a change in the MI protocol but one of
presentation, so I would put it mi2 -i.e the curent default mi (recall that
-i=mi sets mi_version to 2).

I think a large project like Eclipse should follow GDB development to ensure
that changes in MI that are incompatible with their use aren't made.  At some
stage a gdb-mi@sourceware.org mailing list might be appropriate with patches
also going to gdb-patches.

Since there are likely to be many more changes to MI, I suggest that when we
start making changes for mi3 only, the default remains at mi2.  This will
allow a period of development for mi3 during which changes can be made more
freely.  It could then be made the default level after it has stabilised.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Sat, Mar 18, 2006 at 02:25:14PM +1300, Nick Roberts wrote:
>  > Are there any compatibility concerns, i.e. should we make this change
>  > for mi3 only?  Could some frontend rely on these outputs?  I don't
>  > think Eclipse does - it looks like it has some substantial code
>  > to skip them, though, so at least it is aware of them.
> 
> Unlike Volodya's change, its not a change in the MI protocol but one of
> presentation, so I would put it mi2 -i.e the curent default mi (recall that
> -i=mi sets mi_version to 2).

I don't think it makes a difference - it could confuse consumers of MI2
anyway - that's all I'm worried about.

> I think a large project like Eclipse should follow GDB development to ensure
> that changes in MI that are incompatible with their use aren't made.  At some
> stage a gdb-mi@sourceware.org mailing list might be appropriate with patches
> also going to gdb-patches.

I agree that having frontend developers follow the GDB lists would be a
big help.  But there's some progress for this in the works - more news
to come.

> Since there are likely to be many more changes to MI, I suggest that when we
> start making changes for mi3 only, the default remains at mi2.  This will
> allow a period of development for mi3 during which changes can be made more
> freely.  It could then be made the default level after it has stabilised.

Yes, this is already how we document -i=mi to work.  It's the last
finalized version of the protocol.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Nick Roberts]

 > > Unlike Volodya's change, its not a change in the MI protocol but one of
 > > presentation, so I would put it mi2 -i.e the curent default mi (recall that
 > > -i=mi sets mi_version to 2).

I thought that Volodya was also adding a type field.

 > I don't think it makes a difference - it could confuse consumers of MI2
 > anyway - that's all I'm worried about.

I think it means its generally less likely to make a difference.  In Emacs, I
just take the value of the field amd insert it in the appropriate window at
the appropriate place.  Thats why the type currently gets duplicated in the
locals window.  Removing the type prefix just removes that duplication, I
don't have to make any changes to the lisp code in Emacs.  Adding a field,
however, might break my parser if I'm not expecting it.

However, perhaps you're thinking specifically of Eclipse.

 ...
 > > Since there are likely to be many more changes to MI, I suggest that when
 > > we start making changes for mi3 only, the default remains at mi2.  This
 > > will allow a period of development for mi3 during which changes can be
 > > made more freely.  It could then be made the default level after it has
 > > stabilised.
 > 
 > Yes, this is already how we document -i=mi to work.  It's the last
 > finalized version of the protocol.

But there have been many changes to mi2, notably adding the fullname field
in several places, since it became the default level.  I'm just suggesting
that we don't have mi4, mi5, mi6 etc because it gets too complicated.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Sat, Mar 18, 2006 at 03:38:42PM +1300, Nick Roberts wrote:
>  > I don't think it makes a difference - it could confuse consumers of MI2
>  > anyway - that's all I'm worried about.
> 
> I think it means its generally less likely to make a difference.  In Emacs, I
> just take the value of the field amd insert it in the appropriate window at
> the appropriate place.  Thats why the type currently gets duplicated in the
> locals window.  Removing the type prefix just removes that duplication, I
> don't have to make any changes to the lisp code in Emacs.  Adding a field,
> however, might break my parser if I'm not expecting it.
> 
> However, perhaps you're thinking specifically of Eclipse.

No, it was just the only one I had handy to test.

I'm unsympathetic if adding a new field breaks your parser; MI
is deliberately arranged so that consumers can ignore new fields
that they don't understand.

Anyway, I think I'm OK with this change, but I want to track down one
more thing first.

>  > > Since there are likely to be many more changes to MI, I suggest that when
>  > > we start making changes for mi3 only, the default remains at mi2.  This
>  > > will allow a period of development for mi3 during which changes can be
>  > > made more freely.  It could then be made the default level after it has
>  > > stabilised.
>  > 
>  > Yes, this is already how we document -i=mi to work.  It's the last
>  > finalized version of the protocol.
> 
> But there have been many changes to mi2, notably adding the fullname field
> in several places, since it became the default level.  I'm just suggesting
> that we don't have mi4, mi5, mi6 etc because it gets too complicated.

Adding the fullname field was considered (as I wrote above) as a
backwards-compatible change.  I don't intend on allowing
incompatible changes to sneak into MI2 (well, hopefully...).
MI3 will be ready when it's ready :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Nick Roberts]

 > Anyway, I think I'm OK with this change, but I want to track down one
 > more thing first.

OK

 > Adding the fullname field was considered (as I wrote above) as a
 > backwards-compatible change.  I don't intend on allowing
 > incompatible changes to sneak into MI2 (well, hopefully...).
 > MI3 will be ready when it's ready :-)

Lets describe in the manual how the (released) protocol might change then to
give developers a certain expectation and so that they can guard against those
changes:

1) New MI commands may be added.  Yes (as front-ends don't need to use them).

2) New fields may be added to the output of any MI command.  Yes.

3) The format of field's content e.g type prefix, may change so parse it
   at your own risk.  Yes, in general?

4) The order of fields may change?  Shouldn't really matter but it might
   resolve inconsistencies.

And we could add to the list as new cases arise.


-- 
Nick                                           http://www.inet.net.nz/~nickrob