From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43763 invoked by alias); 16 Jan 2019 17:21:27 -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 43752 invoked by uid 89); 16 Jan 2019 17:21:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=strategies, Hx-languages-length:1207, satisfactory, forth X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Jan 2019 17:21:24 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x0GHLIND000984 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 Jan 2019 12:21:23 -0500 Received: by simark.ca (Postfix, from userid 112) id 50DE81E7BB; Wed, 16 Jan 2019 12:21:18 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 35DC61E4C2; Wed, 16 Jan 2019 12:21:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 16 Jan 2019 17:21:00 -0000 From: Simon Marchi To: Eli Zaretskii Cc: simon.marchi@ericsson.com, gdb-patches@sourceware.org Subject: Re: [PATCH] doc: Add table of MI versions In-Reply-To: <83pnswcz5t.fsf@gnu.org> References: <20190114203902.11490-1-simon.marchi@ericsson.com> <831s5despw.fsf@gnu.org> <83va2pd8yv.fsf@gnu.org> <83pnswcz5t.fsf@gnu.org> Message-ID: <77e46c6c0f96d1117d74de052e6b0150@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00376.txt.bz2 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. 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. Knowing the GDB version is usually needed anyway, because they need to work around a variety of bugs, not necessarily related to MI. Simon