This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] New GDB/MI command "-info-gdb-mi-command"


> > This patch adds a new GDB/MI command meant for graphical frontends
> > trying to determine whether a given GDB/MI command exists or not.
> > 
> > Examples:
> > 
> >     -info-gdb-mi-command unsupported-command
> >     ^done,command={exists="false"}
> >     (gdb)
> >     -info-gdb-mi-command symbol-list-lines
> >     ^done,command={exists="true"}
> >     (gdb)
> 
> Sounds good to me.
> 
> > +@subheading The @code{-info-gdb-mi-command} Command
> > +@findex -info-gdb-mi-command
> 
> This should be prominently indexed with @cindex entries, as this
> command is very important, and should be easily found.
> 
> > +@subsubheading Synopsis
> > +
> > +@smallexample
> > + -info-gdb-mi-command CMD_NAME
> > +@end smallexample
> > +
> > +Query support for the @sc{gdb/mi} command named @var{CMD_NAME}
> 
> Ts-ts-ts... ASCII art habits die hard.  Use @var in the example, and
> don't upcase CMD_NAME (it is upcased in Info anyway, and will look
> better in print in lower case).

Thanks for the documentation review. I will fix them and post
a new patch after we confirm the final version of the command.

> > +(the leading dash (@code{-}) in the command name should be omitted).
> 
> Is this wise?  How about if we support both with and without the dash?

It's just easier to program, as this is how commands are stored in
GDB and also looked up by the GDB/MI commadn parser.

This can be argued as weak justification, and it is, but we don't
really need to do any better, IMO.  Since this is a command in a mode
mostly intended for machines, I didn't see the point in supporting
the other version, or both. I still think the current syntax is fine
as clearly documented. But I can implement the more natural one instead,
if we want. I think providing two modes of operation would be overkill,
though.

> > +There is no corresponding @value{GDBN} command.
> 
> Having a way of querying that in CLI would facilitate better .gdbinit
> files, I think.

Can you give some ideas as to how it would be used. I thought this
command to be completely irrelevant to CLI, so didn't even start
to consider the idea of providing it in CLI. Remember also that
you can always execute a GDB/MI command from CLI using
"interpreter-exec".

> > +@smallexample
> > +-info-gdb-mi-command symbol-list-lines
> > +^done,command=@{exists="true"@}
> > +@end smallexample
> 
> Btw, why "command="?  Perhaps "result="?

I don't really have an opinion. I eventually selected "command"
because the output describing a command, and "command" was also
less generic than the first choice I made ("info"). If people
think that "result=" is more MI-like, it's commpletely appropriate
to make the change.

Thanks!
-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]