[mi] -list-features

[mi] -list-features

[Vladimir Prus]

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


Some time ago I've proposed to add MI command
that will list "supported features", to enable
frontends to conditionalize their behaviour easily.
It was generally supported, so here there patch.
So far, no features are reported. OK?

- Volodya

[-- Attachment #2: list_features.ChangeLog --]
[-- Type: text/plain, Size: 142 bytes --]

	* mi/mi-cmds.c (mi_cmds): Register -list-features.
	* mi/mi-cmds.h (mi_cmd_list_features): New.
	* mi/mi-main.c (mi_cmd_list_features): New.

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

--- gdb/mi/mi-cmds.c	(/mirrors/gdb_mainline)	(revision 4644)
+++ gdb/mi/mi-cmds.c	(/patches/gdb/list_features)	(local)
@@ -88,6 +88,7 @@ struct mi_cmd mi_cmds[] =
   { "inferior-tty-set", { NULL, 0 }, NULL, mi_cmd_inferior_tty_set},
   { "inferior-tty-show", { NULL, 0 }, NULL, mi_cmd_inferior_tty_show},
   { "interpreter-exec", { NULL, 0 }, 0, mi_cmd_interpreter_exec},
+  { "list-features", { NULL, 0 }, 0, mi_cmd_list_features},
   { "overlay-auto", { NULL, 0 }, NULL, NULL },
   { "overlay-list-mapping-state", { NULL, 0 }, NULL, NULL },
   { "overlay-list-overlays", { NULL, 0 }, NULL, NULL },
--- gdb/mi/mi-cmds.h	(/mirrors/gdb_mainline)	(revision 4644)
+++ gdb/mi/mi-cmds.h	(/patches/gdb/list_features)	(local)
@@ -91,6 +91,7 @@ extern mi_cmd_argv_ftype mi_cmd_gdb_exit
 extern mi_cmd_argv_ftype mi_cmd_inferior_tty_set;
 extern mi_cmd_argv_ftype mi_cmd_inferior_tty_show;
 extern mi_cmd_argv_ftype mi_cmd_interpreter_exec;
+extern mi_cmd_argv_ftype mi_cmd_list_features;
 extern mi_cmd_argv_ftype mi_cmd_stack_info_depth;
 extern mi_cmd_argv_ftype mi_cmd_stack_info_frame;
 extern mi_cmd_argv_ftype mi_cmd_stack_list_args;
--- gdb/mi/mi-main.c	(/mirrors/gdb_mainline)	(revision 4644)
+++ gdb/mi/mi-main.c	(/patches/gdb/list_features)	(local)
@@ -1075,6 +1075,23 @@ mi_cmd_enable_timings (char *command, ch
   return MI_CMD_ERROR;
 }
 
+enum mi_cmd_result
+mi_cmd_list_features (char *command, char **argv, int argc)
+{
+  if (argc == 0)
+    {
+      struct cleanup *cleanup = NULL;
+      cleanup = make_cleanup_ui_out_list_begin_end (uiout, "features");      
+      
+      do_cleanups (cleanup);
+
+      return MI_CMD_DONE;
+    }
+
+  error ("-list-features should be passed no arguments");
+  return MI_CMD_ERROR;
+}
+ 
 /* Execute a command within a safe environment.
    Return <0 for error; >=0 for ok.
 

Re: [mi] -list-features

[Daniel Jacobowitz]

On Tue, Aug 28, 2007 at 09:11:34PM +0400, Vladimir Prus wrote:
> 
> Some time ago I've proposed to add MI command
> that will list "supported features", to enable
> frontends to conditionalize their behaviour easily.
> It was generally supported, so here there patch.
> So far, no features are reported. OK?

I used the word "features" for something once and then I got myself
completely confused when I had two different things it described.
Can we be more specific?  Features of what?

I think we need proposed documentation more than we need the
implementation for this simple command :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: [mi] -list-features

[Vladimir Prus]

On Tuesday 28 August 2007 21:15:03 Daniel Jacobowitz wrote:
> On Tue, Aug 28, 2007 at 09:11:34PM +0400, Vladimir Prus wrote:
> > 
> > Some time ago I've proposed to add MI command
> > that will list "supported features", to enable
> > frontends to conditionalize their behaviour easily.
> > It was generally supported, so here there patch.
> > So far, no features are reported. OK?
> 
> I used the word "features" for something once and then I got myself
> completely confused when I had two different things it described.
> Can we be more specific?  Features of what?

Of MI.

> I think we need proposed documentation more than we need the
> implementation for this simple command :-)

Ok, guess I won't write texinfo for now, so plain text documentation
would be this:

	-list-features
		Returns a list of particular features of the MI protocol that
		this version of gdb implements.  A feature can be a command,
		or a new field in an output of some command, or even an
		important bugfix.  While a frontend can sometimes detect presence
		of a feature at runtime, it is easier to perform detection at debugger
		startup. The current list of features is:

		- 'frozen-varobjs' -- indicates presence of -var-set-frozen command,
		as well as possible presense of the 'frozen' field in the output of
		-varobj-create.
		.........


- Volodya

Re: [mi] -list-features

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Tue, 28 Aug 2007 21:47:17 +0400
> Cc: gdb-patches@sources.redhat.com
> 
> 	-list-features
> 		Returns a list of particular features of the MI protocol that
> 		this version of gdb implements.  A feature can be a command,
> 		or a new field in an output of some command, or even an
> 		important bugfix.  While a frontend can sometimes detect presence
> 		of a feature at runtime, it is easier to perform detection at debugger
> 		startup. The current list of features is:
> 
> 		- 'frozen-varobjs' -- indicates presence of -var-set-frozen command,
> 		as well as possible presense of the 'frozen' field in the output of
> 		-varobj-create.
> 		.........

This is fine, but for it to be useful to front ends, I think you need
to tell more about the format of the output, because a program will
need to parse and understand it.  Let's say I want to test for the
support of a feature name "frobnicate", how would I go about it?

TIA

Re: [mi] -list-features

[Vladimir Prus]

On Wednesday 29 August 2007 21:55:28 Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Tue, 28 Aug 2007 21:47:17 +0400
> > Cc: gdb-patches@sources.redhat.com
> > 
> > 	-list-features
> > 		Returns a list of particular features of the MI protocol that
> > 		this version of gdb implements.  A feature can be a command,
> > 		or a new field in an output of some command, or even an
> > 		important bugfix.  While a frontend can sometimes detect presence
> > 		of a feature at runtime, it is easier to perform detection at debugger
> > 		startup. The current list of features is:
> > 
> > 		- 'frozen-varobjs' -- indicates presence of -var-set-frozen command,
> > 		as well as possible presense of the 'frozen' field in the output of
> > 		-varobj-create.
> > 		.........
> 
> This is fine, but for it to be useful to front ends, I think you need
> to tell more about the format of the output, because a program will
> need to parse and understand it.  Let's say I want to test for the
> support of a feature name "frobnicate", how would I go about it?

How about this:

        -list-features
                Returns a list of particular features of the MI protocol that
                this version of gdb implements.  A feature can be a command,
                or a new field in an output of some command, or even an
                important bugfix.  While a frontend can sometimes detect presence
                of a feature at runtime, it is easier to perform detection at debugger
                startup. 

		The command returns a list of strings, with each string naming an
		available feature. Each returned string is just a name, it does not
		have any internal structure. The list of possible feature names 
		is given below.

		The current list of features is:

                - 'frozen-varobjs' -- indicates presence of -var-set-frozen command,
                as well as possible presense of the 'frozen' field in the output of
                -varobj-create.

- Volodya

Re: [mi] -list-features

[Nick Roberts]

 > How about this:
 > 
 >         -list-features Returns a list of particular features of the MI
 >                 protocol that this version of gdb implements.  A feature can
 >                 be a command, or a new field in an output of some command,
 >                 or even an important bugfix.  While a frontend can sometimes
 >                 detect presence of a feature at runtime, it is easier to
 >                 perform detection at debugger startup.
 > 
 > 		The command returns a list of strings, with each string naming
 > 		an available feature. Each returned string is just a name, it
 > 		does not have any internal structure. The list of possible
 > 		feature names is given below.
 > 
 > 		The current list of features is:
 > 
 >                 - 'frozen-varobjs' -- indicates presence of -var-set-frozen
 >                 command, as well as possible presense of the 'frozen' field
 >                 in the output of -varobj-create.

You've lost me.  This is plain text documentation for a command which you
want to implement now but populate later.  Something like:

(gdb)
-list-features
^done,features=[]

AFAICS it won't currently return 'frozen-varobjs.  Since everyone seems
agreeable to the general idea why not just submit when the patch (source and
documentation) are complete?

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

Re: [mi] -list-features

[Vladimir Prus]

On Friday 31 August 2007 11:27:19 Nick Roberts wrote:
>  > How about this:
>  > 
>  >         -list-features Returns a list of particular features of the MI
>  >                 protocol that this version of gdb implements.  A feature can
>  >                 be a command, or a new field in an output of some command,
>  >                 or even an important bugfix.  While a frontend can sometimes
>  >                 detect presence of a feature at runtime, it is easier to
>  >                 perform detection at debugger startup.
>  > 
>  > 		The command returns a list of strings, with each string naming
>  > 		an available feature. Each returned string is just a name, it
>  > 		does not have any internal structure. The list of possible
>  > 		feature names is given below.
>  > 
>  > 		The current list of features is:
>  > 
>  >                 - 'frozen-varobjs' -- indicates presence of -var-set-frozen
>  >                 command, as well as possible presense of the 'frozen' field
>  >                 in the output of -varobj-create.
> 
> You've lost me.  This is plain text documentation for a command which you
> want to implement now but populate later.  Something like:
> 
> (gdb)
> -list-features
> ^done,features=[]
> 
> AFAICS it won't currently return 'frozen-varobjs.  Since everyone seems
> agreeable to the general idea why not just submit when the patch (source and
> documentation) are complete?

Now you've lost me. Is this (plain text) documentation fine with you, or not?

- Volodya

Re: [mi] -list-features

[Nick Roberts]

 > > You've lost me.  This is plain text documentation for a command which you
 > > want to implement now but populate later.  Something like:
 > > 
 > > (gdb)
 > > -list-features
 > > ^done,features=[]
 > > 
 > > AFAICS it won't currently return 'frozen-varobjs.  Since everyone seems
 > > agreeable to the general idea why not just submit when the patch (source
 > > and documentation) are complete?
 > 
 > Now you've lost me. Is this (plain text) documentation fine with you, or
 > not?

You've not answered my question.  To answer yours: I think it's fine for the
incomplete patch that you propose but when you define the output syntax of
-list-features:

^done,features=[feature="frozen-varobjs",feature="something",...] ?

^done,features={"frozen-varobjs","something",..} ?

then this should be included too.

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

Re: [mi] -list-features

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 31 Aug 2007 11:05:37 +0400
> Cc: drow@false.org,
>  gdb-patches@sources.redhat.com
> 
> How about this:
> 
>         -list-features
>                 Returns a list of particular features of the MI protocol that
>                 this version of gdb implements.  A feature can be a command,
>                 or a new field in an output of some command, or even an
>                 important bugfix.  While a frontend can sometimes detect presence
>                 of a feature at runtime, it is easier to perform detection at debugger
>                 startup. 
> 
> 		The command returns a list of strings, with each string naming an
> 		available feature. Each returned string is just a name, it does not
> 		have any internal structure. The list of possible feature names 
> 		is given below.

It is still ambiguous, because "a list of string" does not tell the
whole story.  Is it

    foo bar baz
or
    "foo" "bar" "baz"
or
    foo,bar,baz
or
    {foo,bar,baz}
or
    ...

You get the story.

I think an example will go a long way towards disambiguating this.

Thanks.

Re: [mi] -list-features

[Vladimir Prus]

On Friday 31 August 2007 12:50:46 Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 31 Aug 2007 11:05:37 +0400
> > Cc: drow@false.org,
> >  gdb-patches@sources.redhat.com
> > 
> > How about this:
> > 
> >         -list-features
> >                 Returns a list of particular features of the MI protocol that
> >                 this version of gdb implements.  A feature can be a command,
> >                 or a new field in an output of some command, or even an
> >                 important bugfix.  While a frontend can sometimes detect presence
> >                 of a feature at runtime, it is easier to perform detection at debugger
> >                 startup. 
> > 
> > 		The command returns a list of strings, with each string naming an
> > 		available feature. Each returned string is just a name, it does not
> > 		have any internal structure. The list of possible feature names 
> > 		is given below.
> 
> It is still ambiguous, because "a list of string" does not tell the
> whole story.  Is it
> 
>     foo bar baz
> or
>     "foo" "bar" "baz"
> or
>     foo,bar,baz
> or
>     {foo,bar,baz}

Well, in MI, "list of strings" is quite well defined. But if you like, how about this:

	    -list-features
                Returns a list of particular features of the MI protocol that
                this version of gdb implements.  A feature can be a command,
                or a new field in an output of some command, or even an
                important bugfix.  While a frontend can sometimes detect presence
                of a feature at runtime, it is easier to perform detection at debugger
                startup. 

                The command returns a list of strings, with each string naming an
                available feature. Each returned string is just a name, it does not
                have any internal structure. The list of possible feature names 
                is given below.

		Example output:

			^done,result=["feature1","feature2"]

                The current list of features is:

                - 'frozen-varobjs' -- indicates presence of -var-set-frozen command,
                as well as possible presense of the 'frozen' field in the output of
                -varobj-create.

- Volodya

Re: [mi] -list-features

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 31 Aug 2007 13:00:36 +0400
> Cc: drow@false.org,
>  gdb-patches@sources.redhat.com
> 
> > It is still ambiguous, because "a list of string" does not tell the
> > whole story.  Is it
> > 
> >     foo bar baz
> > or
> >     "foo" "bar" "baz"
> > or
> >     foo,bar,baz
> > or
> >     {foo,bar,baz}
> 
> Well, in MI, "list of strings" is quite well defined.

I don't see such a definition.  I see a definition of "list", but if
you want to rely on that, please add a cross-reference to that
section, because the reader shouldn't be required to remember the
syntax by heart.

> 		Example output:
> 
> 			^done,result=["feature1","feature2"]

This is much better, IMO; now it's perfectly clear what front ends
should expect.

Thanks.

Re: [mi] -list-features

[Nick Roberts]

 > > 		Example output:
 > > 
 > > 			^done,result=["feature1","feature2"]
 > 
 > This is much better, IMO; now it's perfectly clear what front ends
 > should expect.

Actually, I think that the output syntax means it should be something like:

^done,result=[name="feature1",name="feature2"]

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

Re: [mi] -list-features

[Vladimir Prus]

On Friday 31 August 2007 13:33:03 Nick Roberts wrote:
>  > > 		Example output:
>  > > 
>  > > 			^done,result=["feature1","feature2"]
>  > 
>  > This is much better, IMO; now it's perfectly clear what front ends
>  > should expect.
> 
> Actually, I think that the output syntax means it should be something like:
> 
> ^done,result=[name="feature1",name="feature2"]

From MI grammar:

	result-record →
        	  [ token ] "^" result-class ( "," result )* nl

	result-class →
          "done" | "running" | "connected" | "error" | "exit"

	result →
        	 variable "=" value

Given 

	^done,result=["feature1","feature2"]

"done" is result class, and

	result=["feature1","feature2"]

is the 'result' nonterminal -- where 'result' is the name and

	["feature1","feature2"]

is the value. Now back to grammar:

	value → const | tuple | list

	list → "[]" | "[" value ( "," value )* "]" | "[" result ( "," result )* "]"
	

So clearly, 

	["feature1","feature2"]

is a valid list and the output I gave is also valid. What you wrote:

	^done,result=[name="feature1",name="feature2"]

is also permitted by the current grammar, but I don't see any possible
meaning in the "name=". I believe using variable names inside lists
is old usage, and new commands should not do that. In contrast, tuples are
in the form:

	{name1=value1,name2=value2,....}

and the names are required for tuples. Are you sure you haven't confused tuples
and lists?

- Volodya

Re: [mi] -list-features

[Nick Roberts]

 > So clearly, 
 > 
 > 	["feature1","feature2"]
 > 
 > is a valid list and the output I gave is also valid. 

I don't think this syntax is possible using the functions ui_out_field_string,
etc.  but if you tried to implement your proposal we would find out for
sure and wouldn't need to debate it.

 >                                                       What you wrote:
 > 
 > 	^done,result=[name="feature1",name="feature2"]
 > 
 > is also permitted by the current grammar, but I don't see any possible
 > meaning in the "name=". I believe using variable names inside lists
 > is old usage, and new commands should not do that. In contrast, tuples are
 > in the form:
 > 
 > 	{name1=value1,name2=value2,....}
 > 
 > and the names are required for tuples. Are you sure you haven't confused tuples
 > and lists?

-stack-list-locals 0
^done,locals=[name="aaa",name="zxcv"]
(gdb) 

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

Re: [mi] -list-features

[Vladimir Prus]

On Friday 31 August 2007 14:01:57 Nick Roberts wrote:
>  > So clearly, 
>  > 
>  > 	["feature1","feature2"]
>  > 
>  > is a valid list and the output I gave is also valid. 
> 
> I don't think this syntax is possible using the functions ui_out_field_string,
> etc.  but if you tried to implement your proposal we would find out for
> sure and wouldn't need to debate it.

I *did* implemented it, and posted a code patch and here's what I get in
my local copy (with two dummy features, for local testing)

	(gdb)
	-list-features
	^done,features=["feature1","feature2"]

>  >                                                       What you wrote:
>  > 
>  > 	^done,result=[name="feature1",name="feature2"]
>  > 
>  > is also permitted by the current grammar, but I don't see any possible
>  > meaning in the "name=". I believe using variable names inside lists
>  > is old usage, and new commands should not do that. In contrast, tuples are
>  > in the form:
>  > 
>  > 	{name1=value1,name2=value2,....}
>  > 
>  > and the names are required for tuples. Are you sure you haven't confused tuples
>  > and lists?
> 
> -stack-list-locals 0
> ^done,locals=[name="aaa",name="zxcv"]
> (gdb) 

This is historical code and gdb manual say this:

	 New GDB/MI commands should only output lists containing values.


- Volodya

 

Re: [mi] -list-features

[Nick Roberts]

 > > I don't think this syntax is possible using the functions
 > > ui_out_field_string, etc.  but if you tried to implement your proposal we
 > > would find out for sure and wouldn't need to debate it.
 > 
 > I *did* implemented it, and posted a code patch and here's what I get in
 > my local copy (with two dummy features, for local testing)

I've only seen a patch with no features, so I must have missed it.

 >...
 > > -stack-list-locals 0
 > > ^done,locals=[name="aaa",name="zxcv"]
 > > (gdb) 
 > 
 > This is historical code and gdb manual say this:
 > 
 > 	 New GDB/MI commands should only output lists containing values.

OK, I see now that other commands output the other syntax.  I currently just
use a different regexp for each MI command but it must make things harder for
anyone who wants to write a formal parser.

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

Re: [mi] -list-features

[Vladimir Prus]

On Friday 31 August 2007 13:18:17 Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 31 Aug 2007 13:00:36 +0400
> > Cc: drow@false.org,
> >  gdb-patches@sources.redhat.com
> > 
> > > It is still ambiguous, because "a list of string" does not tell the
> > > whole story.  Is it
> > > 
> > >     foo bar baz
> > > or
> > >     "foo" "bar" "baz"
> > > or
> > >     foo,bar,baz
> > > or
> > >     {foo,bar,baz}
> > 
> > Well, in MI, "list of strings" is quite well defined.
> 
> I don't see such a definition.  I see a definition of "list", but if
> you want to rely on that, please add a cross-reference to that
> section, because the reader shouldn't be required to remember the
> syntax by heart.
> 
> > 		Example output:
> > 
> > 			^done,result=["feature1","feature2"]
> 
> This is much better, IMO; now it's perfectly clear what front ends
> should expect.

Okay, I've tried to put that in texinfo, and got stuck. My plain text included this:

	 The current list of features is:

                - 'frozen-varobjs' -- indicates presence of -var-set-frozen command,
                as well as possible presense of the 'frozen' field in the output of
                -varobj-create.

How do I express this in texinfo?

Thanks,
Volodya

Re: [mi] -list-features

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 31 Aug 2007 14:18:42 +0400
> Cc: drow@false.org,
>  gdb-patches@sources.redhat.com
> 
> Okay, I've tried to put that in texinfo, and got stuck. My plain text included this:
> 
> 	 The current list of features is:
> 
>                 - 'frozen-varobjs' -- indicates presence of -var-set-frozen command,
>                 as well as possible presense of the 'frozen' field in the output of
>                 -varobj-create.
> 
> How do I express this in texinfo?

Use @itemize, like this:

    The current list of features is:

    @itemize @minus
    @item
    @samp{frozen-varobjs}---indicates presence of the
    @code{-var-set-frozen} command, as well as possible presense of the
    @code{frozen} field in the output of @code{-varobj-create}.
    @end itemize

Re: [mi] -list-features

[Vladimir Prus]

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

On Friday 31 August 2007 13:18:17 Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 31 Aug 2007 13:00:36 +0400
> > Cc: drow@false.org,
> >  gdb-patches@sources.redhat.com
> > 
> > > It is still ambiguous, because "a list of string" does not tell the
> > > whole story.  Is it
> > > 
> > >     foo bar baz
> > > or
> > >     "foo" "bar" "baz"
> > > or
> > >     foo,bar,baz
> > > or
> > >     {foo,bar,baz}
> > 
> > Well, in MI, "list of strings" is quite well defined.
> 
> I don't see such a definition.  I see a definition of "list", but if
> you want to rely on that, please add a cross-reference to that
> section, because the reader shouldn't be required to remember the
> syntax by heart.
> 
> > 		Example output:
> > 
> > 			^done,result=["feature1","feature2"]
> 
> This is much better, IMO; now it's perfectly clear what front ends
> should expect.

Here's the updated patch, including texinfo docs. OK?

- Volodya


[-- Attachment #2: list_features.diff --]
[-- Type: text/x-diff, Size: 3391 bytes --]

--- gdb/doc/gdb.texinfo	(/mirrors/gdb_mainline)	(revision 4740)
+++ gdb/doc/gdb.texinfo	(/patches/gdb/list_features)	(revision 4740)
@@ -21236,6 +21236,37 @@ default shows this information when you 
 (gdb)
 @end smallexample
 
+@subheading The @code{-list-features} Command
+@findex -list-features
+
+Returns a list of particular features of the MI protocol that
+this version of gdb implements.  A feature can be a command,
+or a new field in an output of some command, or even an
+important bugfix.  While a frontend can sometimes detect presence
+of a feature at runtime, it is easier to perform detection at debugger
+startup. 
+
+The command returns a list of strings, with each string naming an
+available feature.  Each returned string is just a name, it does not
+have any internal structure.  The list of possible feature names 
+is given below.
+
+Example output:
+
+@smallexample
+(gdb) -list-features
+^done,result=["feature1","feature2"]
+@end smallexample
+
+The current list of features is:
+
+@itemize @minus
+@item
+@samp{frozen-varobjs}---indicates presence of the
+@code{-var-set-frozen} command, as well as possible presense of the
+@code{frozen} field in the output of @code{-varobj-create}.
+@end itemize
+
 @subheading The @code{-interpreter-exec} Command
 @findex -interpreter-exec
 
--- gdb/mi/mi-cmds.h	(/mirrors/gdb_mainline)	(revision 4740)
+++ gdb/mi/mi-cmds.h	(/patches/gdb/list_features)	(revision 4740)
@@ -91,6 +91,7 @@ extern mi_cmd_argv_ftype mi_cmd_gdb_exit
 extern mi_cmd_argv_ftype mi_cmd_inferior_tty_set;
 extern mi_cmd_argv_ftype mi_cmd_inferior_tty_show;
 extern mi_cmd_argv_ftype mi_cmd_interpreter_exec;
+extern mi_cmd_argv_ftype mi_cmd_list_features;
 extern mi_cmd_argv_ftype mi_cmd_stack_info_depth;
 extern mi_cmd_argv_ftype mi_cmd_stack_info_frame;
 extern mi_cmd_argv_ftype mi_cmd_stack_list_args;
--- gdb/mi/mi-main.c	(/mirrors/gdb_mainline)	(revision 4740)
+++ gdb/mi/mi-main.c	(/patches/gdb/list_features)	(revision 4740)
@@ -1075,6 +1075,25 @@ mi_cmd_enable_timings (char *command, ch
   return MI_CMD_ERROR;
 }
 
+enum mi_cmd_result
+mi_cmd_list_features (char *command, char **argv, int argc)
+{
+  if (argc == 0)
+    {
+      struct cleanup *cleanup = NULL;
+      cleanup = make_cleanup_ui_out_list_begin_end (uiout, "features");      
+
+      ui_out_field_string (uiout, NULL, "frozen-varobjs");
+      
+      do_cleanups (cleanup);
+
+      return MI_CMD_DONE;
+    }
+
+  error ("-list-features should be passed no arguments");
+  return MI_CMD_ERROR;
+}
+ 
 /* Execute a command within a safe environment.
    Return <0 for error; >=0 for ok.
 
--- gdb/mi/mi-cmds.c	(/mirrors/gdb_mainline)	(revision 4740)
+++ gdb/mi/mi-cmds.c	(/patches/gdb/list_features)	(revision 4740)
@@ -88,6 +88,7 @@ struct mi_cmd mi_cmds[] =
   { "inferior-tty-set", { NULL, 0 }, NULL, mi_cmd_inferior_tty_set},
   { "inferior-tty-show", { NULL, 0 }, NULL, mi_cmd_inferior_tty_show},
   { "interpreter-exec", { NULL, 0 }, 0, mi_cmd_interpreter_exec},
+  { "list-features", { NULL, 0 }, 0, mi_cmd_list_features},
   { "overlay-auto", { NULL, 0 }, NULL, NULL },
   { "overlay-list-mapping-state", { NULL, 0 }, NULL, NULL },
   { "overlay-list-overlays", { NULL, 0 }, NULL, NULL },

Property changes on: 
___________________________________________________________________
Name: svk:merge
 +e7755896-6108-0410-9592-8049d3e74e28:/mirrors/gdb/trunk:181223

Re: [mi] -list-features

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Sat, 8 Sep 2007 00:26:00 +0400
> Cc: drow@false.org,
>  gdb-patches@sources.redhat.com
> 
> Here's the updated patch, including texinfo docs. OK?

Yes.

> +Returns a list of particular features of the MI protocol that
> +this version of gdb implements.  A feature can be a command,
                   ^^^
Please use @value{GDBN} here.  Sorry if this was in the original patch
and I didn't pay attention.

Btw, I think this new feature is NEWS-worthy.

Thanks.

Re: [mi] -list-features

[Vladimir Prus]

Eli Zaretskii wrote:

>> From: Vladimir Prus <ghost@cs.msu.su>
>> Date: Sat, 8 Sep 2007 00:26:00 +0400
>> Cc: drow@false.org,
>>  gdb-patches@sources.redhat.com
>> 
>> Here's the updated patch, including texinfo docs. OK?
> 
> Yes.
> 
>> +Returns a list of particular features of the MI protocol that
>> +this version of gdb implements.  A feature can be a command,
>                    ^^^
> Please use @value{GDBN} here.  Sorry if this was in the original patch
> and I didn't pay attention.

Thanks for review. Dan, you disliked the naming of the new command
and planned to comment, do you still plan to?

- Volodya

Re: [mi] -list-features

[Daniel Jacobowitz]

On Sun, Sep 16, 2007 at 06:22:59PM +0400, Vladimir Prus wrote:
> Thanks for review. Dan, you disliked the naming of the new command
> and planned to comment, do you still plan to?

Oh, sorry.  It's fine with me.  I think it's a little generic but we
can use more specific names for other ones if we need them later.

-- 
Daniel Jacobowitz
CodeSourcery