From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1326 invoked by alias); 19 Oct 2004 13:51:41 -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 1315 invoked from network); 19 Oct 2004 13:51:39 -0000 Received: from unknown (HELO lakermmtao10.cox.net) (68.230.240.29) by sourceware.org with SMTP; 19 Oct 2004 13:51:39 -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 <20041019135138.YHJM15775.lakermmtao10.cox.net@white>; Tue, 19 Oct 2004 09:51:38 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CJuOn-0007vw-00; Tue, 19 Oct 2004 09:51:37 -0400 Date: Tue, 19 Oct 2004 19:28:00 -0000 From: Bob Rossi To: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041019135137.GB30345@white> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <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> <20041019131953.GA30345@white> <20041019132824.GA20954@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041019132824.GA20954@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00357.txt.bz2 On Tue, Oct 19, 2004 at 09:28:24AM -0400, Daniel Jacobowitz wrote: > On Tue, Oct 19, 2004 at 09:19:53AM -0400, 'Bob Rossi' wrote: > > 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? > > I think it's pretty clear that no one else likes the idea of > negotiating. I certainly don't. > > I believe that printing the latest stable version of MI is plenty > adequate. If the front end wants a development version of MI it can > use -i=mi; if it wants the latest stable version it can use that > version; if it does not recognize that version it can use the latest > version it recognizes. If you encounter a situation in which that > version no longer works, have it removed from GDB. OK, I want to make it clear that I think this solution is terrible. However, hoping that the GDB community knows more than I, I'll agree. Starting GDB with -i=mi will not change the MI output. However, starting GDB with -i=mi will have GDB print the latest stable version even though it will start GDB in it's latest development version or the latest stable version. For some odd reason in this mode, GDB will print the latest stable version even though it may have absolutely nothing to do with the version it will be communicating with. So, I'll basically start GDB with -i=mi and get the latest stable version. However, since I won't know what version I just started GDB in, the version it just spat out, or a development version, I'll *have* to restart GDB no matter what. So, I'll read the first line ( which is the latest stable version ), and then kill GDB and restart it in the mode that I support. This solution, * *requires* a restart * requires printing the latest stable version even though GDB may not be even speaking that version * says *nothing* about other versions that GDB supports * gives no way for a front end to determine if it is using a deprecated protocol. * puts the bug finding of the MI protocol on the users, even though the protocols have been deprecated. If this is the wish of the GDB community, then this is what I'll implement. Thanks, Bob Rossi