From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27217 invoked by alias); 6 Oct 2004 12:30:45 -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 27201 invoked from network); 6 Oct 2004 12:30:43 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 6 Oct 2004 12:30:43 -0000 Received: from zaretski ([80.230.143.237]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CTL71665 (AUTH halo1); Wed, 6 Oct 2004 14:30:06 +0200 (IST) Date: Wed, 06 Oct 2004 13:19:00 -0000 From: "Eli Zaretskii" To: Bob Rossi Message-ID: <01c4ab9f$Blat.v2.2.2$e9a87e60@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: drow@false.org, gdb@sources.redhat.com In-reply-to: <20041006112703.GB11747@white> (message from Bob Rossi on Wed, 6 Oct 2004 07:27:03 -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> <01c4ab8d$Blat.v2.2.2$93dba3c0@zahav.net.il> <20041006112703.GB11747@white> X-SW-Source: 2004-10/txt/msg00123.txt.bz2 > Date: Wed, 6 Oct 2004 07:27:03 -0400 > From: Bob Rossi > Cc: Daniel Jacobowitz , gdb@sources.redhat.com > > > 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. > > This is not correct. The front end has parsers for different versions of > GDB's MI protocol. The parser for MI2 will not work for the MI3 protocol In general, it won't, but for a very specific case of _a_single_command_, it could very well do. Obviously, we will need to agree to _never_ change the syntax of the output of that command once it is introduced, but that is all we need to do to make sure _every_ MI parser henceforth will understand that command's output. > The front end *can not* start up GDB just by using -interpreter=mi > because it doesn't know what parser to use in this situation. > Can we agree on this point for starters? Obviously, I disagree: if the syntax of what that command outputs does not change, you should be able to use _any_ MI parser that knows about this command; in particularly, the latest MI parser will do, so invoking GDB with "-interpreter=mi" will solve the problem. Can we agree on this point? > > > 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? > > Yes, of course they do :) > xxgdb, ddd, gvd, ... > They all use annotations and they all assume annotate 1 is around. As > soon as you pull annotate 1, they will all have the same problem. So how these front ends solve this problem now? > > 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. > > This is wrong. I *need* the output to have *all* the versions of MI that > the current GDB supports. I need this for a very very simple reason. I > need to make sure that my front ends that don't support the current > official release of GDB can start GDB in the highest mode it supports. I still don't see the problem, sorry. Your front end surely knows (or can know) what is the latest MI version it supports, right? If so, the following simple algorithm should do what you want: get the latest stable MI version from GDB, call it $mi-ver if $mi-ver is greater than N, the latest MI version supported by the front-end then restart GDB with "-interpreter=miN" else either set up to use the parser for $mi-ver or restart GDB with "-interpreter=mi" endif What am I missing? > If at some point, GDB decides not to honor MI2 anymore, I need to make > sure that I know that. If my front end only supports MI2, and GDB > supports only MI3, than the function you are suggesting will not be good > enough for me. If that happens, invoking GDB with "-interpreter=mi2" will exit with a failure status and print an error message. That should be enough for the front end to say that it cannot work with such a GDB, if MI2 is the only MI version the front end understands. Still no problem that I see; do you?