From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118732 invoked by alias); 16 Jan 2019 20:57:44 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 118717 invoked by uid 89); 16 Jan 2019 20:57:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Enterprise, discovery, H*r:sk:mailout, Hx-spam-relays-external:sk:mailout X-HELO: mailout01.t-online.de Received: from mailout01.t-online.de (HELO mailout01.t-online.de) (194.25.134.80) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Jan 2019 20:57:41 +0000 Received: from fwd21.aul.t-online.de (fwd21.aul.t-online.de [172.20.27.66]) by mailout01.t-online.de (Postfix) with SMTP id AAE7D42287F6; Wed, 16 Jan 2019 21:57:38 +0100 (CET) Received: from localhost (rXRsecZZghtkSu0wOTkM4LjNTEMrwxZ4J+VU8qif3ut1TZp91hjn6OfP2Abd8EbZ1n@[91.65.68.176]) by fwd21.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1gjsFg-0Iqfr60; Wed, 16 Jan 2019 21:57:32 +0100 Date: Wed, 16 Jan 2019 20:57:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Simon Marchi Cc: Eli Zaretskii , simon.marchi@ericsson.com, gdb-patches@sourceware.org Subject: Re: [PATCH] doc: Add table of MI versions Message-ID: <20190116205902.GB2948@klara.mpi.htwm.de> References: <20190114203902.11490-1-simon.marchi@ericsson.com> <831s5despw.fsf@gnu.org> <83va2pd8yv.fsf@gnu.org> <83pnswcz5t.fsf@gnu.org> <77e46c6c0f96d1117d74de052e6b0150@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77e46c6c0f96d1117d74de052e6b0150@polymtl.ca> X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00384.txt.bz2 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'