From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26546 invoked by alias); 14 Oct 2004 15:37:27 -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 26263 invoked from network); 14 Oct 2004 15:37:21 -0000 Received: from unknown (HELO lakermmtao06.cox.net) (68.230.240.33) by sourceware.org with SMTP; 14 Oct 2004 15:37:21 -0000 Received: from white ([68.9.64.121]) by lakermmtao06.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041014153719.BWJI13490.lakermmtao06.cox.net@white>; Thu, 14 Oct 2004 11:37:19 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CI7fM-0006It-00; Thu, 14 Oct 2004 11:37:20 -0400 Date: Thu, 14 Oct 2004 19:34:00 -0000 From: 'Bob Rossi' To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041014153720.GA24199@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> <20041013003135.GA22087@white> <01c4b0df$Blat.v2.2.2$e933d3e0@zahav.net.il> <20041013121412.GA22696@white> <01c4b163$Blat.v2.2.2$7d934a60@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4b163$Blat.v2.2.2$7d934a60@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00316.txt.bz2 On Wed, Oct 13, 2004 at 10:29:31PM +0200, Eli Zaretskii wrote: > > Date: Wed, 13 Oct 2004 08:14:12 -0400 > > From: 'Bob Rossi' > > Cc: gdb@sources.redhat.com > > > > > What's wrong with a simpler idea already suggested here: that GDB will > > > output the MI version as part of the starting blurb when invoked with > > > "-interpreter=mi" option? > > > > That method is fine if GDB supports only one stable MI protocol at a > > time. However, I have been told that GDB will support multiple versions > > of MI at a time. > > Yes, but Andrew just told you that GDB will most probably support at > most 2 MI versions: the latest one and the one before that. So > printing only the last version is okay, because if that version is not > supported by your front end, you need only to check the previous > version. Isn't that good enough? > > (Even if GDB does support more than 2 MI versions, you could still > probe smaller versions until you either (1) find one that is okay with > your front end, or (2) get GDB to fail because the MI version you > requested is not supported. I can give several reasons why this is not good enough. As far as I can tell, there are 3 types of MI protocols. Supported, unsupported and developmental. This information needs to be given to the front end. For example, right now GDB supports MI2. However, if a front end understood only MI1, then it would be tempted to try MI1 with your approach. However, MI1 is unsupported and most likely doesn't work. It would be nice if the front end was capable of understanding that. > And if that is still not good enough, let's have GDB output a list of > supported MI versions as part of its starting blurb, e.g. one version > per line. This seems reasonable. There are 2 down sides that I don't like * There is no handshaking being done. Average case scenario is starting GDB twice to get it into the correct mode. Once to find out the supported versions, second to start it in the correct mode. * It tells the front end only the minimum information it needs to know. (developmental and unsupported interfaces are not printed) Again, this probably isn't to important. If we implement the handshaking solution that I had, it is guaranteed that the front end will be able to start GDB only once and get it into the correct MI protocol. What is wrong with the handshaking protocol that I described? I see it as the optimal solution and would be happy to implement it. > Will that finally put this issue to rest? I understand this issue is long and drawn out, however, it is critical for a front end to GDB that plans on working with multiple GDB's and not just one that is bundled together. Thanks for helping out! Thanks, Bob Rossi