From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 541 invoked by alias); 11 Oct 2004 14:12:13 -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 476 invoked from network); 11 Oct 2004 14:12:10 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 11 Oct 2004 14:12:10 -0000 Received: from white ([68.9.64.121]) by lakermmtao01.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041011141210.FAVA24917.lakermmtao01.cox.net@white>; Mon, 11 Oct 2004 10:12:10 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CH0uH-0005Bo-00; Mon, 11 Oct 2004 10:12:09 -0400 Date: Mon, 11 Oct 2004 17:46:00 -0000 From: 'Bob Rossi' To: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041011141209.GE18844@white> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20041007145511.GA14573@white> <200410071614.MAA19648@smtp.ott.qnx.com> <20041007224230.GA15177@white> <01c4ad12$Blat.v2.2.2$1796ec80@zahav.net.il> <20041009002901.GB16824@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041009002901.GB16824@white> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00281.txt.bz2 On Fri, Oct 08, 2004 at 08:29:01PM -0400, 'Bob Rossi' wrote: > On Fri, Oct 08, 2004 at 10:36:45AM +0200, Eli Zaretskii wrote: > > > Date: Thu, 7 Oct 2004 18:42:30 -0400 > > > From: 'Bob Rossi' > > > Cc: Dave Korn , gdb@sources.redhat.com > > > > > > * Have GDB output it's last stable version of MI as the first thing > > > it outputs (subset of case above) > > > > Will this solution be satisfactory for you? That is, when invoked > > with the -interpreter=mi command-line switch, GDB will print the > > last stable version of the MI protocol it supports. This is actually > > the way many protocol negotiations start, and I don't see why we > > shouldn't behave the same. > > > > Note that a front end which wants to support older GDB versions will > > need to have a database of MI versions referenced by GDB versions, > > because the old GDB versions will not print the MI version. > > > > Are there any disadvantages to this solution? > > Sorry for the delay, I am waiting on the answer for these questions > http://sources.redhat.com/ml/gdb/2004-10/msg00267.html > before I can say if this will be OK for me. > > Bob Rossi OK, I have received an answer. Basically GDB has already, and may in the future support multiple versions of MI. The solution above is perfect if GDB supports one stable version of MI, however, if it supports multiple versions of MI, the front end still needs to tell GDB which version it wants to use. I have come up with a crude patch that makes GDB work like this, the '>' means that GDB is outputting data to the front end, and the '<' means that GDB is inputting data from the front end. $ ./gdb -i=mi-handshake >mi1 >mi2 >mi3 ~"GNU gdb 6.2.50_2004-10-08-cvs\n" >... >(gdb) Basically, just to get the idea, GDB outputs all of the MI front end's that it supports, and then allows the front end to choose one. All of this happens before GDB initializes the interpreter, so that after the choice is made, GDB does not have to be restarted and will work with the protocol selected by the front end. Any ideas? Obviously we could define the handshaking better, and allow for development vs stable releases to be made clear. Also, make room for future extensions and make a grammar, .. Thanks, Bob Rossi