From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27048 invoked by alias); 14 Oct 2004 21:23:08 -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 27020 invoked from network); 14 Oct 2004 21:23:06 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 14 Oct 2004 21:23:06 -0000 Received: from zaretski ([80.230.156.217]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CVW52674 (AUTH halo1); Thu, 14 Oct 2004 23:22:42 +0200 (IST) Date: Fri, 15 Oct 2004 13:02:00 -0000 From: "Eli Zaretskii" To: "'Bob Rossi'" Message-ID: <01c4b233$Blat.v2.2.2$873cc700@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb@sources.redhat.com In-reply-to: <20041014153720.GA24199@white> (message from 'Bob Rossi' on Thu, 14 Oct 2004 11:37:20 -0400) Subject: Re: probing GDB for MI versions Reply-to: Eli Zaretskii 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> <20041014153720.GA24199@white> X-SW-Source: 2004-10/txt/msg00320.txt.bz2 > Date: Thu, 14 Oct 2004 11:37:20 -0400 > From: 'Bob Rossi' > Cc: gdb@sources.redhat.com > > > 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. I was only talking about stable versions, so developmental is not something we should consider (we've been through this and decided that it is unsafe to use such versions). > 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. If MI1 is not working and the front end only supports MI1, then this combination of GDB and front end is not going to work. So I submit that this case is not interesting: you will try MI1 and things will go wrong at some point. However, ``unsupported'' and ``doesn't work'' are not the same thing. If we know that a certain version of MI does not work, we should remove its support from GDB. If we didn't do that, then we have good reasons to believe that MI1 does in fact work. > It would be > nice if the front end was capable of understanding that. And then do what? print a message "like unsupported GDB version"? Is this really an interesting case? I thought you were interested in getting a front end to _work_ with MI; graceful failure is something different. Can we please solve one problem at a time? Do you agree that if either (1) the front end supports the latest stable version or (2) the version before that works reasonably well, then printing only the latest stable version at startup is good enough? > 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. I don't see this as a grave problem. > * 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. Indeed. > What is wrong with the handshaking protocol that I described? It is too complicated for the job, IMHO.