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

["André Pönitz" <andre.poenitz@mathematik.tu-chemnitz.de>]

On Wed, Nov 13, 2013 at 06:15:14AM +0400, Joel Brobecker wrote:
> > I am not sure I agree with the judgement of benefits here. The basic 
> > yes/no information is already there:
> > 
> >     (gdb) -unsupported-command
> >     ^error,msg="Undefined MI command: unsupported-command"
> >     (gdb) -symbol-list-lines
> >     ^error,msg="-symbol-list-lines: Usage: SOURCE_FILENAME"
> > 
> > It's not nice, but "works".
> 
> I disagree with your assessment of "works". I can think of a number
> of scenarios where this would be problematic:
> 
> The first and most obvious to me is the case where the debugger is
> run with a non-English LANG. If you base your detection on parsing
> the error msg, then i18n ruins your plan.

For me the context was "frontends". I assume they run external tools in an
environment that's as predictable as they need. If a user defined LANG is
problematic for a frontend, I would assume the frontend forces debugger
startup in a LANG that it knows to handle.

> And if you base your detection on the presence of the error alone, then
> commands that take no argument may return an error, which by no means
> indicates that the command does not exist.

I also assumed that such error message will not start with "Undefined
MI command:". 

> > In addition, a yes-or-no is not even what might be needed.
> 
> Well, the IDE team at AdaCore needs that information in order to support
> the variety of GDB versions out there, and I also agreed with them that
> this was a sensible request.

That's fine. You want a feature, and you implement it, and you are in a
position to get it in. I was merely jumping on the plural in "frontend_s_"
and only because I mistook that as "all", not as "possibly more than one".

> > Look e.g. at the "python" advertisement in -list-features output
> > ^done,features=["frozen-varobjs","pending-breakpoints","thread-info",
> > "data-read-memory-bytes","breakpoint-notifications","ada-task-info","python"]
> > 
> > It does not indicate whether it is properly installed (datadir...) nor
> > whether the version of Python is compatible with the script I want to
> > execute. So in practice, checking -list-features is just extra effort
> > giving only a subset of the information I would need for an "ok to use"
> > decision, and it's quicker and more reliable to just execute the
> > command and handle errors.
> > 
> > It's hard to imagine that this will ever cover enough of GDB features
> > and questions a frontend needs to have answered.
> 
> If we were discussing about the specific issues regarding the use of
> Python in your example, I would say that this is outside the scope of
> this new command.

We really aren't. "python" is an obvious case, but I could also have used
"thread-info" as example. Why should a frontend ask whether "-thread-info"
is supported, parse output, and switch code paths between "-thread-info"
and "info threads" (and hope that an announcement of "-thread-info"
existence is backed by an implementation) when it could just fire
"-thread-info" and handle a possible error by falling back on "info
thread"?

This would mean that users of well-behaved gdb builds/installation lose one
roundtrip, and the frontend needs to implement three funtions (ask, either,
or) instead of two (call, fallback)

> If you are trying to make a general point, then can you please tell us
> how you think we can improve it? If not, you are free to find it useless
> and to prefer to just use your execution test.

I was indeeed trying to make a general point insofar as that I think it
does not help users to introduce, or strengthen, a _third_ way to
describe "the state of the nation" (first being actual behaviour of the
code, second the documentation, potential third the -info-gdb-mi-command
output). 

I actually think this very thread proves the point. You said "Recently, I
added new coommands for Ada exception$ catching, but forgot about
-list-features" which means there _are_ builds of gdb which support the
feature, but don't announce it.

Anyway, to finish this: My fourth assumption was that the "[RFC]" in the
subject  was short-hand for "Request for comments" and that "interested
parties" were invited to comment. But I got it now.  

Regards,
Andre'