This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] New GDB/MI command "-info-gdb-mi-command"
- From: André Pönitz <andre dot poenitz at mathematik dot tu-chemnitz dot de>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Wed, 13 Nov 2013 23:03:22 +0100
- Subject: Re: [RFC] New GDB/MI command "-info-gdb-mi-command"
- Authentication-results: sourceware.org; auth=none
- References: <8761rzknb4 dot fsf at fleche dot redhat dot com> <1384255504-28444-1-git-send-email-brobecker at adacore dot com> <20131112205229 dot GA7068 at klara dot mpi dot htwm dot de> <20131113021514 dot GG3481 at adacore dot com>
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
> > 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
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
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.