From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4317 invoked by alias); 6 Oct 2004 10:19:54 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4306 invoked from network); 6 Oct 2004 10:19:52 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sourceware.org with SMTP; 6 Oct 2004 10:19:52 -0000 Received: from zaretski ([80.230.143.237]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DUU64517 (AUTH halo1); Wed, 6 Oct 2004 12:18:51 +0200 (IST) Date: Wed, 06 Oct 2004 11:14:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c4ab8d$Blat.v2.2.2$93dba3c0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: bob@brasko.net, gdb@sources.redhat.com In-reply-to: <20041005140736.GC13586@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 5 Oct 2004 10:07:36 -0400) Subject: Re: GDB/MI snapshots between major release's Reply-to: Eli Zaretskii References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> <200410041533.i94FXsPa014648@juw15.nfra.nl> <20041004155805.GF8121@white> <01c4aabb$Blat.v2.2.2$e64c8fc0@zahav.net.il> <20041005140736.GC13586@nevyn.them.org> X-SW-Source: 2004-10/txt/msg00116.txt.bz2 > Date: Tue, 5 Oct 2004 10:07:36 -0400 > From: Daniel Jacobowitz > Cc: Bob Rossi , kettenis@gnu.org, gdb@sources.redhat.com > > I think using a command line switch makes sense. You're going to have > to restart GDB to change MI protocols anyway, so why force the user to > go into MI? First, it is possible that when the front end knows which MI version is the last stable one, it will not need to restart GDB, but just arrange for the appropriate parser to be used for the rest of the session. And second, even if you do need to restart, it makes sense to have this command in the MI so that the same parser could be used to do the job of finding the MI version(s) as well, instead of having a special code that parses the ouput of a command-line option. A downside of the command-line option that I very much don't like is that command-line options are mainly for the human users and are documented in a special section that describes how to run GDB, not how to use the MI interpreter. > I also like the idea of listing non-MI (which right now means annotate) > protocols in the same output. Does some front end need that? If not, why introduce unneeded generalizations? I actually think that the output of the feature we are discussing needs to be a single string: the latest version of MI supported by this GDB that is known to be stable. Given that info, the front end should be able to figure out all the stable versions it can use: they are those whose version numbers are below the latest stable one.