From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29747 invoked by alias); 6 Oct 2004 11:27:26 -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 29543 invoked from network); 6 Oct 2004 11:27:08 -0000 Received: from unknown (HELO lakermmtao07.cox.net) (68.230.240.32) by sourceware.org with SMTP; 6 Oct 2004 11:27:08 -0000 Received: from white ([68.9.64.121]) by lakermmtao07.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006112704.PUAE28213.lakermmtao07.cox.net@white>; Wed, 6 Oct 2004 07:27:04 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CF9wl-000346-00; Wed, 06 Oct 2004 07:27:03 -0400 Date: Wed, 06 Oct 2004 11:39:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041006112703.GB11747@white> Mail-Followup-To: Eli Zaretskii , Daniel Jacobowitz , gdb@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4ab8d$Blat.v2.2.2$93dba3c0@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00118.txt.bz2 On Wed, Oct 06, 2004 at 12:15:40PM +0200, Eli Zaretskii wrote: > > 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. 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 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? This is why there needs to be a non-MI command to figure out what MI versions the current GDB supports. > 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. Yes, this is a downside, but I don't think your MI solution is quite ready for use, however, maybe we could come up with something better still. > > 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. Emacs uses annotate 1, probably annotate 2 at some version and now annotate 3 at some version. Also, I believe it's moving into the MI realm .... what a mess ... > 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. 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. Bob Rossi