[MI] -stack-list-variables

[MI] -stack-list-variables

[Vladimir Prus]

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


MI presently have two separate commands to list locals and arguments in
the current frame. Most often than not, frontend need both, so having
to emit two commands is inconvenience and and extra roundtrip. I believe
Nick has suggested having a single command, and Andre is in favour of
this idea, and I also think it's good. I actually recall than Nick planned
to write a patch, but I did not saw any, and this is fairly trivial
change, so here it goes. The new command is called -stack-list-variables,
and it's checked in into  CVS HEAD.

I'll post doc patch shortly; I will also merge this to 7.0 after a couple
of days, if no issues appear.


Thanks,
Volodya

[-- Attachment #2: stack-list-variables.diff --]
[-- Type: text/x-patch, Size: 6185 bytes --]

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.10882
diff -u -p -r1.10882 ChangeLog
--- ChangeLog	19 Sep 2009 09:46:45 -0000	1.10882
+++ ChangeLog	19 Sep 2009 09:58:45 -0000
@@ -1,3 +1,13 @@
+2009-09-19  Vladimir Prus  <vladimir@codesourcery.com>
+
+	* mi/mi-cmds.h (mi_cmd_stack_list_variables): Declare.
+	* mi/mi-cmds.c (mi_cmds): Register -stack-list-variables.
+	* mi/mi-cmd-stack.c (enum what_to_list): New.
+	(list_args_or_locals): Accept what_to_list parameter.
+	Use 'variables' as output name of all are requested.
+	(mi_cmd_stack_list_variables): New.
+	(mi_cmd_stack_list_locals, mi_cmd_stack_list_args): Adjust.
+
 2009-09-19  Eli Zaretskii  <eliz@gnu.org>
 
 	* config/djgpp/fnchange.lst: Add missing edits.
Index: mi/mi-cmd-stack.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-stack.c,v
retrieving revision 1.44
diff -u -p -r1.44 mi-cmd-stack.c
--- mi/mi-cmd-stack.c	30 Jun 2009 09:37:23 -0000	1.44
+++ mi/mi-cmd-stack.c	19 Sep 2009 09:58:45 -0000
@@ -32,7 +32,11 @@
 #include "language.h"
 #include "valprint.h"
 
-static void list_args_or_locals (int locals, int values, struct frame_info *fi);
+
+enum what_to_list { locals, arguments, all };
+
+static void list_args_or_locals (enum what_to_list what, 
+				 int values, struct frame_info *fi);
 
 /* Print a list of the stack frames. Args can be none, in which case
    we want to print the whole backtrace, or a pair of numbers
@@ -148,7 +152,7 @@ mi_cmd_stack_list_locals (char *command,
 
    frame = get_selected_frame (NULL);
 
-   list_args_or_locals (1, parse_print_values (argv[0]), frame);
+   list_args_or_locals (locals, parse_print_values (argv[0]), frame);
 }
 
 /* Print a list of the arguments for the current frame. With argument
@@ -204,19 +208,37 @@ mi_cmd_stack_list_args (char *command, c
       QUIT;
       cleanup_frame = make_cleanup_ui_out_tuple_begin_end (uiout, "frame");
       ui_out_field_int (uiout, "level", i);
-      list_args_or_locals (0, print_values, fi);
+      list_args_or_locals (arguments, print_values, fi);
       do_cleanups (cleanup_frame);
     }
 
   do_cleanups (cleanup_stack_args);
 }
 
+/* Print a list of the local variables (including arguments) for the 
+   current frame. With argument of 0, print only the names, with 
+   argument of 1 print also the values. */
+void
+mi_cmd_stack_list_variables (char *command, char **argv, int argc)
+{
+  struct frame_info *frame;
+  enum print_values print_values;
+
+  if (argc != 1)
+    error (_("Usage: PRINT_VALUES"));
+
+   frame = get_selected_frame (NULL);
+
+   list_args_or_locals (all, parse_print_values (argv[0]), frame);
+}
+
+
 /* Print a list of the locals or the arguments for the currently
    selected frame.  If the argument passed is 0, printonly the names
    of the variables, if an argument of 1 is passed, print the values
    as well. */
 static void
-list_args_or_locals (int locals, int values, struct frame_info *fi)
+list_args_or_locals (enum what_to_list what, int values, struct frame_info *fi)
 {
   struct block *block;
   struct symbol *sym;
@@ -225,12 +247,23 @@ list_args_or_locals (int locals, int val
   struct cleanup *cleanup_list;
   static struct ui_stream *stb = NULL;
   struct type *type;
+  char *name_of_result;
 
   stb = ui_out_stream_new (uiout);
 
   block = get_frame_block (fi, 0);
 
-  cleanup_list = make_cleanup_ui_out_list_begin_end (uiout, locals ? "locals" : "args");
+  switch (what)
+    {
+    case locals:
+      name_of_result = "locals"; break;
+    case arguments:
+      name_of_result = "args"; break;
+    case all:
+      name_of_result = "variables"; break;
+    }
+
+  cleanup_list = make_cleanup_ui_out_list_begin_end (uiout, name_of_result);
 
   while (block != 0)
     {
@@ -259,8 +292,12 @@ list_args_or_locals (int locals, int val
 	    case LOC_STATIC:	/* static                */
 	    case LOC_REGISTER:	/* register              */
 	    case LOC_COMPUTED:	/* computed location     */
-	      if (SYMBOL_IS_ARGUMENT (sym) ? !locals : locals)
+	      if (what == all)
 		print_me = 1;
+	      else if (what == locals)
+		print_me = !SYMBOL_IS_ARGUMENT (sym);
+	      else
+		print_me = SYMBOL_IS_ARGUMENT (sym);
 	      break;
 	    }
 	  if (print_me)
@@ -273,7 +310,7 @@ list_args_or_locals (int locals, int val
 		  make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
 	      ui_out_field_string (uiout, "name", SYMBOL_PRINT_NAME (sym));
 
-	      if (!locals)
+	      if (SYMBOL_IS_ARGUMENT (sym))
 		sym2 = lookup_symbol (SYMBOL_NATURAL_NAME (sym),
 				      block, VAR_DOMAIN,
 				      (int *) NULL);
Index: mi/mi-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
retrieving revision 1.43
diff -u -p -r1.43 mi-cmds.c
--- mi/mi-cmds.c	15 Sep 2009 18:51:25 -0000	1.43
+++ mi/mi-cmds.c	19 Sep 2009 09:58:45 -0000
@@ -89,6 +89,7 @@ struct mi_cmd mi_cmds[] =
   { "stack-list-arguments", { NULL, 0 }, mi_cmd_stack_list_args},
   { "stack-list-frames", { NULL, 0 }, mi_cmd_stack_list_frames},
   { "stack-list-locals", { NULL, 0 }, mi_cmd_stack_list_locals},
+  { "stack-list-variables", { NULL, 0 }, mi_cmd_stack_list_variables},
   { "stack-select-frame", { NULL, 0 }, mi_cmd_stack_select_frame},
   { "symbol-list-lines", { NULL, 0 }, mi_cmd_symbol_list_lines},
   { "target-attach", { "attach", 1 }, NULL },
Index: mi/mi-cmds.h
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.h,v
retrieving revision 1.40
diff -u -p -r1.40 mi-cmds.h
--- mi/mi-cmds.h	15 Sep 2009 18:51:25 -0000	1.40
+++ mi/mi-cmds.h	19 Sep 2009 09:58:45 -0000
@@ -75,6 +75,7 @@ extern mi_cmd_argv_ftype mi_cmd_stack_in
 extern mi_cmd_argv_ftype mi_cmd_stack_list_args;
 extern mi_cmd_argv_ftype mi_cmd_stack_list_frames;
 extern mi_cmd_argv_ftype mi_cmd_stack_list_locals;
+extern mi_cmd_argv_ftype mi_cmd_stack_list_variables;
 extern mi_cmd_argv_ftype mi_cmd_stack_select_frame;
 extern mi_cmd_argv_ftype mi_cmd_symbol_list_lines;
 extern mi_cmd_argv_ftype mi_cmd_target_detach;

Re: [MI] -stack-list-variables

[Vladimir Prus]

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

Vladimir Prus wrote:

> 
> MI presently have two separate commands to list locals and arguments in
> the current frame. Most often than not, frontend need both, so having
> to emit two commands is inconvenience and and extra roundtrip. I believe
> Nick has suggested having a single command, and Andre is in favour of
> this idea, and I also think it's good. I actually recall than Nick planned
> to write a patch, but I did not saw any, and this is fairly trivial
> change, so here it goes. The new command is called -stack-list-variables,
> and it's checked in into  CVS HEAD.
> 
> I'll post doc patch shortly; I will also merge this to 7.0 after a couple
> of days, if no issues appear.

And here's the doc patch.

- Volodya

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

? ChangeLog.lines
? ChangeLog.my
? all
? my
Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.626
diff -u -p -r1.626 gdb.texinfo
--- gdb.texinfo	18 Sep 2009 18:03:45 -0000	1.626
+++ gdb.texinfo	19 Sep 2009 10:10:47 -0000
@@ -23130,6 +23130,9 @@ The @var{show-values} argument must have
 0 means that only the names of the arguments are listed, a value of 1
 means that both names and values of the arguments are printed.
 
+Use of this command to obtain arguments in a single frame is
+deprecated in favor of the @samp{-stack-list-variables} command.
+
 @subsubheading @value{GDBN} Command
 
 @value{GDBN} does not have an equivalent command.  @code{gdbtk} has a
@@ -23314,6 +23317,9 @@ display the value of simple data types a
 other data types when the user wishes to explore their values in
 more detail.
 
+This command is deprecated in favor of the
+@samp{-stack-list-variables} command.
+
 @subsubheading @value{GDBN} Command
 
 @samp{info locals} in @value{GDBN}, @samp{gdb_get_locals} in @code{gdbtk}.
@@ -23334,6 +23340,31 @@ more detail.
 (gdb)
 @end smallexample
 
+@subheading The @code{-stack-list-variables} Command
+@findex -stack-list-variables
+
+@subsubheading Synopsis
+
+@smallexample
+ -stack-list-variables @var{print-values}
+@end smallexample
+
+Display the names of local variables and function arguments for the selected frame.  If
+@var{print-values} is 0 or @code{--no-values}, print only the names of
+the variables; if it is 1 or @code{--all-values}, print also their
+values; and if it is 2 or @code{--simple-values}, print the name,
+type and value for simple data types and the name and type for arrays,
+structures and unions.  
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-stack-list-variables --thread 1 --frame 0 --all-values
+^done,variables=[{name="x",value="11"},{name="s",value="{a = 1, b = 2}"}]
+(gdb)
+@end smallexample
+
 
 @subheading The @code{-stack-select-frame} Command
 @findex -stack-select-frame

Re: [MI] -stack-list-variables

[Eli Zaretskii]

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Sat, 19 Sep 2009 14:13:35 +0400
> 
> And here's the doc patch.

OK.

Re: [MI] -stack-list-variables

[Vladimir Prus]

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

Vladimir Prus wrote:

> 
> MI presently have two separate commands to list locals and arguments in
> the current frame. Most often than not, frontend need both, so having
> to emit two commands is inconvenience and and extra roundtrip. I believe
> Nick has suggested having a single command, and Andre is in favour of
> this idea, and I also think it's good. I actually recall than Nick planned
> to write a patch, but I did not saw any, and this is fairly trivial
> change, so here it goes. The new command is called -stack-list-variables,
> and it's checked in into  CVS HEAD.
> 
> I'll post doc patch shortly; I will also merge this to 7.0 after a couple
> of days, if no issues appear.

On IRC, Matt Rice told me that gcc 4.5 complains that 'name_of_result' is
potentially uninitialized. Now, that warnings is most utterly bogus, but
I've checked in the workaround below.

- Volodya


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

? A.diff
? commit_1.diff
? include.diff
? stack-list-variables.diff
? doc/ChangeLog.lines
? doc/ChangeLog.my
? doc/all
? doc/my
? doc/stack-list-variables-docs.diff
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.10883
diff -u -p -r1.10883 ChangeLog
--- ChangeLog	19 Sep 2009 09:59:29 -0000	1.10883
+++ ChangeLog	19 Sep 2009 11:12:03 -0000
@@ -1,5 +1,10 @@
 2009-09-19  Vladimir Prus  <vladimir@codesourcery.com>
 
+	* mi/mi-cmd-stack.c (list_args_or_locals): Workaround
+	gcc warning.
+
+2009-09-19  Vladimir Prus  <vladimir@codesourcery.com>
+
 	* mi/mi-cmds.h (mi_cmd_stack_list_variables): Declare.
 	* mi/mi-cmds.c (mi_cmds): Register -stack-list-variables.
 	* mi/mi-cmd-stack.c (enum what_to_list): New.
Index: mi/mi-cmd-stack.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-stack.c,v
retrieving revision 1.45
diff -u -p -r1.45 mi-cmd-stack.c
--- mi/mi-cmd-stack.c	19 Sep 2009 09:59:29 -0000	1.45
+++ mi/mi-cmd-stack.c	19 Sep 2009 11:12:04 -0000
@@ -261,6 +261,8 @@ list_args_or_locals (enum what_to_list w
       name_of_result = "args"; break;
     case all:
       name_of_result = "variables"; break;
+    default:
+      gdb_assert (("unexpected value", 0));
     }
 
   cleanup_list = make_cleanup_ui_out_list_begin_end (uiout, name_of_result);

Re: [MI] -stack-list-variables

[Joel Brobecker]

Hi,

I just noticed a couple of things while glancing at the patch...

> +/* Print a list of the local variables (including arguments) for the 
> +   current frame. With argument of 0, print only the names, with 
                    ^ Space missing

> +   argument of 1 print also the values. */

I also found the comment a little confusing.  I would probably have
said that ARGC must be 1 or an error is thown, and to see
parse_print_values for a list of valid values for ARGV[0].
(there is no comment for parse_print_value, btw).

> +  if (argc != 1)
> +    error (_("Usage: PRINT_VALUES"));
> +
> +   frame = get_selected_frame (NULL);
> +
> +   list_args_or_locals (all, parse_print_values (argv[0]), frame);

The indentation of the last couple of statements is off by one.

-- 
Joel

Re: [MI] -stack-list-variables

[Joel Brobecker]

> +2009-09-19  Vladimir Prus  <vladimir@codesourcery.com>
> +
> +	* mi/mi-cmds.h (mi_cmd_stack_list_variables): Declare.
> +	* mi/mi-cmds.c (mi_cmds): Register -stack-list-variables.
> +	* mi/mi-cmd-stack.c (enum what_to_list): New.
> +	(list_args_or_locals): Accept what_to_list parameter.
> +	Use 'variables' as output name of all are requested.
> +	(mi_cmd_stack_list_variables): New.
> +	(mi_cmd_stack_list_locals, mi_cmd_stack_list_args): Adjust.

ARG, the part that I really wanted to mentioned, and yet I forgot
after fussing on details. Sorry.

Can we have some tests added to the testsuite?

-- 
Joel

Re:[MI] -stack-list-variables

[Nick Roberts]

>                             ...The new command is called -stack-list-variables,
> and it's checked in into  CVS HEAD.

I don't like this patch/commit for a couple of reasons.  One reason I
proposed such a command was to move away from the loose syntax that MI
uses.  In particular to move away from:


    `LIST ==>'
         ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )* "]" '

to

    `LIST ==>'
         ` "[]" | "[" VALUE ( "," VALUE )* "]" '


to provide a more JSON-like syntax.

As with -stack-list-locals, the new output can give something like:

-stack-list-variables --no-values
^done,variables=[name="i",name="j",name="asdf",name="m",name="zxcv",name="qwert"]

but to keep JSON-like syntax, this needs to be:

-stack-list-variables --no-values
^done,variables=[{name="i"},{name="j"},{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]

which leads to my second point:

Which `variables' are the arguments and which are locals?
Arguments might be a kind of local but they're not identical.

How about the format below?:

-stack-list-variables --no-values
^done,variables={args=[{name="i"},{name="j"}],
                 locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}


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

Re: [MI] -stack-list-variables

[Vladimir Prus]

On Sunday 20 September 2009 Nick Roberts wrote:

> >                             ...The new command is called -stack-list-variables,
> > and it's checked in into  CVS HEAD.
> 
> I don't like this patch/commit for a couple of reasons.  One reason I
> proposed such a command was to move away from the loose syntax that MI
> uses.  In particular to move away from:
> 
> 
>     `LIST ==>'
>          ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )* "]" '
> 
> to
> 
>     `LIST ==>'
>          ` "[]" | "[" VALUE ( "," VALUE )* "]" '
> 
> 
> to provide a more JSON-like syntax.
> 
> As with -stack-list-locals, the new output can give something like:
> 
> -stack-list-variables --no-values
> ^done,variables=[name="i",name="j",name="asdf",name="m",name="zxcv",name="qwert"]
> 
> but to keep JSON-like syntax, this needs to be:
> 
> -stack-list-variables --no-values
> ^done,variables=[{name="i"},{name="j"},{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]

Well, with values printed, the output is:

	-stack-list-variables --thread 1 --frame 0 --all-values
	^done,variables=[{name="x",value="11"},{name="s",value="{a = 1, b = 2}"}]

and is therefore OK. It's no-values case that takes shortcuts. However,
I plan a follow-up patch really soon now that will make -stack-list-variables
output a block where each variable defined. As result, there will be
two attributes for each variable, and the output above will be used in
all cases, regardless of whether printing of values was requested.

> which leads to my second point:
> 
> Which `variables' are the arguments and which are locals?
> Arguments might be a kind of local but they're not identical.
> 
> How about the format below?:
> 
> -stack-list-variables --no-values
> ^done,variables={args=[{name="i"},{name="j"}],
>                  locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}

Why would frontend care about which are locals and which are arguments? I don't
think I saw any GUI than distinguish between those in variables view. Even
if we decide this information is necessary, would it not be better to present it
like this:

	^done,variables=[{name="i", arg="1"},{name="asdf"}]

as this format is more extensible in case some other frontend might need
even more finer details?

- Volodya

Re: [MI] -stack-list-variables

[Nick Roberts]

 > > How about the format below?:
 > > 
 > > -stack-list-variables --no-values
 > > ^done,variables={args=[{name="i"},{name="j"}],
 > >                  locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}
 > 
 > Why would frontend care about which are locals and which are arguments? I don't
 > think I saw any GUI than distinguish between those in variables view.

CLI treats them as completely different ("info args", "info locals") as MI
did previously (-stack-list-locals, -stack-list-arguments).  To the programmer,
I think they are quite different: argument values are passed in, local values
aren't.  If the front end doesn't care, it can always group these together.

 >                                                                       Even
 > if we decide this information is necessary, would it not be better to present it
 > like this:
 > 
 > 	^done,variables=[{name="i", arg="1"},{name="asdf"}]
 > 
 > as this format is more extensible in case some other frontend might need
 > even more finer details?

I don't see how this helps.  Breaking locals and args down further would require
a new command for backward compatibilty reasons.

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

Re: [MI] -stack-list-variables

[Vladimir Prus]

Nick Roberts wrote:

>  > > How about the format below?:
>  > > 
>  > > -stack-list-variables --no-values
>  > > ^done,variables={args=[{name="i"},{name="j"}],
>  > >                  locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}
>  > 
>  > Why would frontend care about which are locals and which are arguments? I don't
>  > think I saw any GUI than distinguish between those in variables view.
> 
> CLI treats them as completely different ("info args", "info locals") as MI
> did previously (-stack-list-locals, -stack-list-arguments).  To the programmer,
> I think they are quite different: argument values are passed in, local values
> aren't.  

That's only the "origin" of the values. Inside the function, parameters and locals
obey exactly the same rules.

> If the front end doesn't care, it can always group these together. 

I was saying that all frontends I know do not seem to care, therefore it
does not seem like we should care.

>  >                                                                       Even
>  > if we decide this information is necessary, would it not be better to present it
>  > like this:
>  > 
>  > ^done,variables=[{name="i", arg="1"},{name="asdf"}]
>  > 
>  > as this format is more extensible in case some other frontend might need
>  > even more finer details?
> 
> I don't see how this helps.  Breaking locals and args down further would require
> a new command for backward compatibilty reasons.

Why? You can always add new field, e.g.

        ^done,variables=[{name="i", truly-magic-kind-of-symbol="1"},{name="asdf"}]

?

- Volodya


 

Re: [MI] -stack-list-variables

[Nick Roberts]

 > That's only the "origin" of the values. Inside the function, parameters and locals
 > obey exactly the same rules.

If you are trying to understand how a variable gets a value then you're interested
in the origin of that value.

 > > If the front end doesn't care, it can always group these together. 
 > 
 > I was saying that all frontends I know do not seem to care, therefore it
 > does not seem like we should care.

I don't really know what other frontends do but it appears useful to me.

 > >  >                                                                       Even
 > >  > if we decide this information is necessary, would it not be better to present it
 > >  > like this:
 > >  > 
 > >  > ^done,variables=[{name="i", arg="1"},{name="asdf"}]
 > >  > 
 > >  > as this format is more extensible in case some other frontend might need
 > >  > even more finer details?
 > > 
 > > I don't see how this helps.  Breaking locals and args down further would require
 > > a new command for backward compatibilty reasons.
 > 
 > Why? You can always add new field, e.g.
 > 
 >         ^done,variables=[{name="i", truly-magic-kind-of-symbol="1"},{name="asdf"}]

Perhaps I misunderstood.  I thought you mean't a third kind of local, whatever that might
be, but we could equally add a new field like this too:


^done,variables={args=[{name="i", truly-magic-kind-of-symbol="1"},{name="j"}],
                 locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}



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

Re: [MI] -stack-list-variables

[Vladimir Prus]

On Monday 21 September 2009 Nick Roberts wrote:

>  > That's only the "origin" of the values. Inside the function, parameters and locals
>  > obey exactly the same rules.
> 
> If you are trying to understand how a variable gets a value then you're interested
> in the origin of that value.
> 
>  > > If the front end doesn't care, it can always group these together. 
>  > 
>  > I was saying that all frontends I know do not seem to care, therefore it
>  > does not seem like we should care.
> 
> I don't really know what other frontends do but it appears useful to me.
> 
>  > >  >                                                                       Even
>  > >  > if we decide this information is necessary, would it not be better to present it
>  > >  > like this:
>  > >  > 
>  > >  > ^done,variables=[{name="i", arg="1"},{name="asdf"}]
>  > >  > 
>  > >  > as this format is more extensible in case some other frontend might need
>  > >  > even more finer details?
>  > > 
>  > > I don't see how this helps.  Breaking locals and args down further would require
>  > > a new command for backward compatibilty reasons.
>  > 
>  > Why? You can always add new field, e.g.
>  > 
>  >         ^done,variables=[{name="i", truly-magic-kind-of-symbol="1"},{name="asdf"}]
> 
> Perhaps I misunderstood.  I thought you mean't a third kind of local, whatever that might
> be, but we could equally add a new field like this too:
> 
> 
> ^done,variables={args=[{name="i", truly-magic-kind-of-symbol="1"},{name="j"}],
>                  locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}

So, those general approaches are essentially equivalent in their expressive power?
In which case, it seems reasonable to pick the approach that more directly correspond
to what current frontends need, namely a flat list of variables. Should a frontend
appear that will want to explicitly show args/locals distinctions, we can also
add the necessary field. So, we're open for future extensibility, without immediately
introducing syntax that no frontend might ever end up needed.

- Volodya

Re: [MI] -stack-list-variables

[Joel Brobecker]

> > If the front end doesn't care, it can always group these together. 
> 
> I was saying that all frontends I know do not seem to care, therefore it
> does not seem like we should care.

But what would happen the day a front-end starts caring? Are they
going to have to send 2 MI commands to get the info?

-- 
Joel

Re: [MI] -stack-list-variables

[Vladimir Prus]

On Monday 21 September 2009 Joel Brobecker wrote:

> > > If the front end doesn't care, it can always group these together. 
> > 
> > I was saying that all frontends I know do not seem to care, therefore it
> > does not seem like we should care.
> 
> But what would happen the day a front-end starts caring? Are they
> going to have to send 2 MI commands to get the info?

No. The frontend author would write an email to gdb@sources.redhat.com,
explaining the reasons, and a new field will be added as result. That's
how I'd prefer MI to evolve, as opposed to adding information ahead of
the time.

- Volodya

Re: [MI] -stack-list-variables

[Joel Brobecker]

> > But what would happen the day a front-end starts caring? Are they
> > going to have to send 2 MI commands to get the info?
> 
> No. The frontend author would write an email to gdb@sources.redhat.com,
> explaining the reasons, and a new field will be added as result. That's
> how I'd prefer MI to evolve, as opposed to adding information ahead of
> the time.

This is just my 2 cents, of course, but Nick's suggestion to separate
locals from arguments seems fairly reasonable. Why not add the field
now, and make that feature available now, rather than later?  I can
certainly see why a front-end would want that separation. Seems like
Nick, who AFAIK helps maintaining emacs/gud, would use it.

-- 
Joel

Re: [MI] -stack-list-variables

[Vladimir Prus]

On Monday 21 September 2009 Joel Brobecker wrote:

> > > But what would happen the day a front-end starts caring? Are they
> > > going to have to send 2 MI commands to get the info?
> > 
> > No. The frontend author would write an email to gdb@sources.redhat.com,
> > explaining the reasons, and a new field will be added as result. That's
> > how I'd prefer MI to evolve, as opposed to adding information ahead of
> > the time.
> 
> This is just my 2 cents, of course, but Nick's suggestion to separate
> locals from arguments seems fairly reasonable. Why not add the field
> now, and make that feature available now, rather than later? 

Because we can always add a desired feature, but can never remove an unneeded
one, in fear that some frontend we have no idea about ended up using that
feature.

> I can
> certainly see why a front-end would want that separation. Seems like
> Nick, who AFAIK helps maintaining emacs/gud, would use it.

I am afraid I did not hear an explanation how that will be used. And as
recent MI pretty-printing saga clearly shown, new MI features really have
to be developed in lock-step with frontend changes.

(If you did not follow, the story was that I've drafted some MI interface
for pretty-printing, and them as soon as I've tried to use it from KDevelop,
the interface turned out to be totally lacking).

- Volodya

Re: [MI] -stack-list-variables

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Volodya> I am afraid I did not hear an explanation how that will be
Volodya> used. And as recent MI pretty-printing saga clearly shown, new
Volodya> MI features really have to be developed in lock-step with
Volodya> frontend changes.

I agree that this is true in the general case.  But, in this specific
case, adding the attribute seems harmless.

Tom

Re: [MI] -stack-list-variables

[Vladimir Prus]

On Monday 21 September 2009 Tom Tromey wrote:

> >>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> Volodya> I am afraid I did not hear an explanation how that will be
> Volodya> used. And as recent MI pretty-printing saga clearly shown, new
> Volodya> MI features really have to be developed in lock-step with
> Volodya> frontend changes.
> 
> I agree that this is true in the general case.  But, in this specific
> case, adding the attribute seems harmless.

There's about 10 different attributes we can also print, and they will
be likewise harmless. Should we add them all?

I am frankly surprised by the amount of support for this feature, and
the fact that this support say this is harmless, and possibly
useful, but does not name any single frontend that actually separates
arguments from "true" locals.

- Volodya

Re: [MI] -stack-list-variables

[Tom Tromey]

>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:

Tom> I agree that this is true in the general case.  But, in this specific
Tom> case, adding the attribute seems harmless.

Volodya> There's about 10 different attributes we can also print, and they will
Volodya> be likewise harmless. Should we add them all?

Sure, if someone asks for them.

Furthermore, this is a bogus line of argumentation.  There is no
slippery slope here, there is a specific feature under discussion.

Volodya> I am frankly surprised by the amount of support for this feature, and
Volodya> the fact that this support say this is harmless, and possibly
Volodya> useful, but does not name any single frontend that actually separates
Volodya> arguments from "true" locals.

Apparently Nick wants it for Emacs.

Personally, I agree, it is useless to distinguish them.  I can't
remember ever caring about this distinction, and quite to the contrary,
I am often irritated that the CLI makes it.

If Nick does not in fact want this for Emacs, then yes, I agree, don't
bother.

Tom

RE: [MI] -stack-list-variables

[Marc Khouzam]

 

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker
> Sent: Monday, September 21, 2009 12:28 PM
> To: Vladimir Prus
> Cc: gdb-patches@sources.redhat.com
> Subject: Re: [MI] -stack-list-variables
> 
>>> But what would happen the day a front-end starts caring? Are they
>>> going to have to send 2 MI commands to get the info?
>> 
>> No. The frontend author would write an email to gdb@sources.redhat.com,
>> explaining the reasons, and a new field will be added as result. That's
>> how I'd prefer MI to evolve, as opposed to adding information ahead of
>> the time.

A disadvantage with this approach is that this feature would only be
available in the GDB release that occurred after the feature request.
A frontend that would request the feature could not offer the same 
functionality with older GDBs.  

We can't prepare for everything of course, but in this case, why not?

Just my thoughts

Marc

Re: [MI] -stack-list-variables

[Nick Roberts]

 > > But what would happen the day a front-end starts caring? Are they
 > > going to have to send 2 MI commands to get the info?
 > 
 > No. The frontend author would write an email to gdb@sources.redhat.com,
 > explaining the reasons, and a new field will be added as result. That's
 > how I'd prefer MI to evolve, as opposed to adding information ahead of
 > the time.

That's exactly what I have done.

and:

> I am frankly surprised by the amount of support for this feature, and
> the fact that this support say this is harmless, and possibly
> useful, but does not name any single frontend that actually separates
> arguments from "true" locals.

I'm not sure that `proof by example' should be necessary. but here's an
example showing Totalview separate the two:

http://upc.lbl.gov/docs/user/ProcessWindow.png

Totalview is probably the world's best C/C++ debugger (apart fron GDB, of
course!).  I'm sure that if their users didn't want this feature, Etnus would
remove it.

As a maintainer I would try to accommodate such requests and reserve my
judgements for technical matters.

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

Re: [MI] -stack-list-variables

[Vladimir Prus]

On Tuesday 22 September 2009 Nick Roberts wrote:

>  > > But what would happen the day a front-end starts caring? Are they
>  > > going to have to send 2 MI commands to get the info?
>  > 
>  > No. The frontend author would write an email to gdb@sources.redhat.com,
>  > explaining the reasons, and a new field will be added as result. That's
>  > how I'd prefer MI to evolve, as opposed to adding information ahead of
>  > the time.
> 
> That's exactly what I have done.

Hmm, I must have missed. You never said that you want to implement this-and-that
in Emacs, and explained why and how. What you said was you consider the separation
"useful", which is considerably more weaker statement. 

Are you actually planning on implementing locals/arg separation in Emacs in
observable timeframe? 


> and:
> 
> > I am frankly surprised by the amount of support for this feature, and
> > the fact that this support say this is harmless, and possibly
> > useful, but does not name any single frontend that actually separates
> > arguments from "true" locals.
> 
> I'm not sure that `proof by example' should be necessary. but here's an
> example showing Totalview separate the two:
> 
> http://upc.lbl.gov/docs/user/ProcessWindow.png
> 
> Totalview is probably the world's best C/C++ debugger 

Uhm, this is very subjective statement (though you seem to use Totalview as
example regularly). Looking on the screenshot, I am not impressed.

> (apart fron GDB, of
> course!).  I'm sure that if their users didn't want this feature, Etnus would
> remove it.

I am not aware how marketing/management/design works at that company, so I
cannot comment on this.

> As a maintainer I would try to accommodate such requests and reserve my
> judgements for technical matters.

I disagree. Sensible frontend interface is only possible if we (or I) understand 
specific use cases that are supported, and how they are supposed, as opposed to
working from requests to add some information to some command.

- Volodya

Re: [MI] -stack-list-variables

[Daniel Jacobowitz]

On Tue, Sep 22, 2009 at 09:31:26AM +0400, Vladimir Prus wrote:
> On Tuesday 22 September 2009 Nick Roberts wrote:
> > As a maintainer I would try to accommodate such requests and reserve my
> > judgements for technical matters.
> 
> I disagree. Sensible frontend interface is only possible if we (or I) understand 
> specific use cases that are supported, and how they are supposed, as opposed to
> working from requests to add some information to some command.

I don't think you, as a single individual, should have to understand
the needs of every frontend.  I don't think any one person understands
every way that GDB can be used.

I'm not sure why this has turned into such a big argument though...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [MI] -stack-list-variables

[Vladimir Prus]

Vladimir Prus wrote:

> On Tuesday 22 September 2009 Nick Roberts wrote:
> 
>>  > > But what would happen the day a front-end starts caring? Are they
>>  > > going to have to send 2 MI commands to get the info?
>>  > 
>>  > No. The frontend author would write an email to gdb@sources.redhat.com,
>>  > explaining the reasons, and a new field will be added as result. That's
>>  > how I'd prefer MI to evolve, as opposed to adding information ahead of
>>  > the time.
>> 
>> That's exactly what I have done.
> 
> Hmm, I must have missed. You never said that you want to implement this-and-that
> in Emacs, and explained why and how. What you said was you consider the separation
> "useful", which is considerably more weaker statement.
> 
> Are you actually planning on implementing locals/arg separation in Emacs in
> observable timeframe?

Nick,

can you please answer the question above? I would like to merge this to 7.0
branch, and for that, I need to close this question.

- Volodya

Re: [MI] -stack-list-variables

[Nick Roberts]

 > > Are you actually planning on implementing locals/arg separation in Emacs in
 > > observable timeframe?

Yes.

-- 
Nick                                           http://users.snap.net.nz/~nickrob