This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] doc: Add table of MI versions
On Wed, Jan 16, 2019 at 12:21:17PM -0500, Simon Marchi wrote:
> On 2019-01-16 12:03, Eli Zaretskii wrote:
> > > I don't think we require front ends to use the lowest common
> > > denominator. Instead, it should request
> > > max(version_known_by_the_front_end, version_known_by_gdb).
> >
> > And I think version_known_by_gdb needs this command, doesn't it?
>
> There are multiple strategies to find this information, this could be one.
> A front end could start GDB with "-i=mi" and issue -mi-version to get it.
> It can then determine whether that version is satisfactory or if it should
> restart GDB with an earlier version of MI.
>
> Another strategy, for a frontend that knows mi1, mi2 and mi3, could be to
> try to start GDB with "-i=mi3" first. If GDB exits immediately with
> "Interpreter `mi3' unrecognized", try with mi2, and so forth.
Sounds unlikely to me. I'd rather expect frontends to simply cope with
all versions of possible outputs they are aware of. The case that started
this discussion here is straight-forward to handle, for instance.
> The frontends I have worked with parse the output of "gdb --version" to find
> the GDB version, so they could deduce which MI version to use based on that.
> It's not pretty, since different builds of GDB can have different looking
> version strings but it works well enough.
That's impressive. I've seen e.g. version strings like
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
GNU gdb (GDB) 7.0.1-debian
GNU gdb (GDB) 7.0.90.20100226-cvs
GNU gdb (GDB) 7.1-ubuntu
GNU gdb (GDB) 7.3 qnx (rev. 613)
GNU gdb (GDB) Fedora (7.1-22.fc13)
GNU gdb (GDB) Fedora 8.0-13.fc26
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
GNU gdb (GDB; SUSE Linux Enterprise 10) 7.9.1
GNU gdb (GDB; openSUSE 13.1) 7.6.50.20130731-cvs
GNU gdb (Gentoo 7.1 p1) 7.1
GNU gdb (rubenvb-4.7.2-release) 7.5.50.20120920-cvs
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2)
GNU gdb Fedora (6.8-37.el5)
Yes, I can try to parse a GDB release from that, and I can guess
on available features from that but I never ended up with something
reasonable robust that way.
One cannot even assume that the same base GDB release works the same
everywhere as different distributions pile different local patches on top.
> Knowing the GDB version is usually needed anyway, because they
> need to work around a variety of bugs, not necessarily related to MI.
"Feature discovery" can also work by trial-and-error: Try one syntax,
if that fails, take the next one. This can even be cached per session
in most cases.
Andre'