From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17280 invoked by alias); 19 Oct 2004 13:20:00 -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 17237 invoked from network); 19 Oct 2004 13:19:54 -0000 Received: from unknown (HELO lakermmtao10.cox.net) (68.230.240.29) by sourceware.org with SMTP; 19 Oct 2004 13:19:54 -0000 Received: from white ([68.9.64.121]) by lakermmtao10.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041019131953.XXUK15775.lakermmtao10.cox.net@white>; Tue, 19 Oct 2004 09:19:53 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CJtu5-0007uT-00; Tue, 19 Oct 2004 09:19:53 -0400 Date: Tue, 19 Oct 2004 13:51:00 -0000 From: 'Bob Rossi' To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041019131953.GA30345@white> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20041013003135.GA22087@white> <01c4b0df$Blat.v2.2.2$e933d3e0@zahav.net.il> <20041013121412.GA22696@white> <01c4b163$Blat.v2.2.2$7d934a60@zahav.net.il> <20041014153720.GA24199@white> <01c4b233$Blat.v2.2.2$873cc700@zahav.net.il> <20041015154016.GB25467@white> <01c4b376$Blat.v2.2.2$7cb58440@zahav.net.il> <20041016154611.GA26614@white> <01c4b3a7$Blat.v2.2.2$8533eea0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4b3a7$Blat.v2.2.2$8533eea0@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00354.txt.bz2 On Sat, Oct 16, 2004 at 07:41:32PM +0200, Eli Zaretskii wrote: > > Date: Sat, 16 Oct 2004 11:46:11 -0400 > > From: 'Bob Rossi' > > Cc: gdb@sources.redhat.com > > > > You think that GDB does and will only test one version of the MI > > protocol. > > It's not what I think, it's what Andrew said was the policy. He did? I thought he said "who knows", meaning he didn't know. How could he create policy on this if he doesn't know. >>> * Will GDB support more than one stable MI protocols for a CVS >>> snapshot? Who knows, > > * Will GDB support more than one stable MI protocols for an official release? > > In the past GDB tested both mi1 and mi2 so that that stage they were > > probably described as "supported". Now that only mi2 is tested, nad mi1 is > > deprecated, your call. > > > > With this in mind, I do not think it is OK to print the latest stable > > version only. It does not tell the front end what other versions could > > be stable. > > IIRC, MI1's tests were removed from the CVS as soon as MI2 was deemed > stable enough. So this example doesn't conflict with what I said. > > Anyway, I already suggested to have a list of versions printed at > startup time, if you still think several tested versions of MI will be > available. We seem to go in circles since then. Yes, I understand. If GDB is going to support 1 stable version of the MI protocol at a time then just have it print the version on startup. There is no negotiation that needs to take place. If GDB is going to support multiple stable versions of the MI protocol at a time, then have it print all of the versions like you suggested. Also, above what you suggested, I think the front end should be able to select the version it wants from the list. Is this OK? I'd like to work on this patch as soon as possible, so that I can start using it. Is the multiple stable version approach with negotiation OK? Thanks, Bob Rossi