From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10173 invoked by alias); 16 Oct 2004 11:54:37 -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 10122 invoked from network); 16 Oct 2004 11:54:35 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 16 Oct 2004 11:54:35 -0000 Received: from zaretski ([80.230.157.85]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CWF11315 (AUTH halo1); Sat, 16 Oct 2004 13:54:29 +0200 (IST) Date: Sat, 16 Oct 2004 15:46:00 -0000 From: "Eli Zaretskii" To: "'Bob Rossi'" Message-ID: <01c4b376$Blat.v2.2.2$7cb58440@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb@sources.redhat.com In-reply-to: <20041015154016.GB25467@white> (message from 'Bob Rossi' on Fri, 15 Oct 2004 11:40:17 -0400) Subject: Re: probing GDB for MI versions Reply-to: Eli Zaretskii References: <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> <01c4b233$Blat.v2.2.2$873cc700@zahav.net.il> <20041015154016.GB25467@white> X-SW-Source: 2004-10/txt/msg00337.txt.bz2 > Date: Fri, 15 Oct 2004 11:40:17 -0400 > From: 'Bob Rossi' > Cc: gdb@sources.redhat.com > > I think that supported(tested) and unsupported(untested) are two > entirely different things. Not entirely: an MI version does not become buggy just because you stop testing it. The bit-rotting process takes time, and during that time the untested MI is still working reasonably well. Also, the fact that something is tested does not mean there are no bugs in it. So let's stop talking about absolutes because they are not appropriate here. Let's keep the discussion focused on practical problems, not on principles. > > > 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 consider this a very interesting case. More interesting than the case where the front end _can_ find a working MI version? > I don't want a reasonably well working verion, I want a version that > it tested in the testsuite. Then you must make sure your front end supports the latest stable version, and only that version, and this whole discussion is mostly irrelevant, because just printing the latest stable version is all you need (if the front end doesn't support that version, it should refuse to work). See below. > * printing just the latest stable version > > Is this the version that GDB will start up in if you do -i=mi even if > you are using a CVS snapshot and the version has been bumped? No. The latest stable version is not the one that is invoked with "-i=mi", it is the stable version before that. > This solution is lacking. It only tells the front end the latest > stable version of the MI protocol. The front end can only guess what > other stable versions are available and I consider this unacceptable. According to what Andrew said, and since you don't want to use untested old versions, the latest stable version is all you need. > However, this solution requires starting GDB twice, which I would not > prefer if it was solvable with just starting it once. I don't see any problem in restart, if that is indeed required. However, it sounds like a restart will not be needed, since the front end supports only one version: the latest stable one. Again, if you are unprepared to work with any MI version but the ones that are actively tested by the testsuite, then your front end will need constant work to make it support the latest stable version, and it should refuse to work with any other version.