From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15905 invoked by alias); 3 Oct 2004 16:32:30 -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 15889 invoked from network); 3 Oct 2004 16:32:29 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 3 Oct 2004 16:32:29 -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 <20041003163227.IPCP8969.lakermmtao01.cox.net@white>; Sun, 3 Oct 2004 12:32:27 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CE9Hg-0001pv-00; Sun, 03 Oct 2004 12:32:28 -0400 Date: Sun, 03 Oct 2004 16:39:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: MI and backwards compatibility Message-ID: <20041003163228.GA7030@white> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20041001142517.GD4100@white> <20041002153815.GC5224@white> <01c4a89d$Blat.v2.2.2$ea76c2c0@zahav.net.il> <20041002172449.GE5224@white> <01c4a904$Blat.v2.2.2$9a9c14a0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4a904$Blat.v2.2.2$9a9c14a0@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00026.txt.bz2 On Sun, Oct 03, 2004 at 06:50:07AM +0200, Eli Zaretskii wrote: > > Date: Sat, 2 Oct 2004 13:24:49 -0400 > > From: Bob Rossi > > Cc: gdb@sources.redhat.com > > > > If for example the -break-list command in the MI3 protocol becomes > > incompatible with the -break-list command that was in the MI2 protocol, > > and the MI version is bumped from 2 to 3 because of it, > > > > * will -break-list be left around for old front ends that use MI2 and a > > new MI command -break-list-new be created for front ends that use MI3? > > > > * will -break-list act differently in MI2 mode than it will for MI3 > > mode? > > > > or the very bad broken case, > > > > * will -break-list act the new way in both MI2 and MI3 mode? > > It should be the second alternative. If the first alternative were > true, we wouldn't need to bump the MI version. OK, so the official stance of the MI protocol within GDB is to be backwards compatible, and the commands themselves will act differently for different version of the MI protocol? Does the testsuite still test all of the MI tests for each protocol that the current GDB supports ? I would consider this to be reasonably important, otherwise, I could see that old MI protocol versions would quickly not conform to the output one would expect. > > BTW, I think it would be helpful to put the information on this thread > > in the MI doco, so that front end developers understand the compatibility > > philosophy of GDB's MI interface. > > I don't think it would be a good idea to point people at a mailing > list thread. What we normally do is when some piece of information > like what is discussed in this thread sounds important to have in the > docs, we add the information itself to gdbint.texinfo or some other > relevant documentation file. Yes of course, I was suggesting to add a section maybe called "MI backwards compatibility" that was short and simply just described the philosophy of backwards compatibility of the MI protocol. Thanks, Bob Rossi