From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22957 invoked by alias); 27 Jun 2005 13:56:20 -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 22937 invoked by uid 22791); 27 Jun 2005 13:56:17 -0000 Received: from lakermmtao10.cox.net (HELO lakermmtao10.cox.net) (68.230.240.29) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 27 Jun 2005 13:56:17 +0000 Received: from white ([68.9.64.121]) by lakermmtao10.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050627135611.IUFT7787.lakermmtao10.cox.net@white>; Mon, 27 Jun 2005 09:56:11 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1Dmu5r-00054w-00; Mon, 27 Jun 2005 09:56:11 -0400 Date: Mon, 27 Jun 2005 13:56:00 -0000 From: Bob Rossi To: Nick Roberts Cc: Daniel Jacobowitz , Mark Kettenis , gdb@sourceware.org Subject: Re: MI-related testsuite regressions Message-ID: <20050627135610.GA19376@white> References: <200506270815.j5R8FZO6026261@jop31.nfra.nl> <17087.60064.541364.938844@farnswood.snap.net.nz> <20050627130030.GA10394@nevyn.them.org> <17088.1264.104928.522819@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17088.1264.104928.522819@farnswood.snap.net.nz> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-06/txt/msg00259.txt.bz2 > > > Currently the default MI interpreter *is* > > > mi2, so these tests are just duplicated. It would seem sensible, and save > > > effort, to have just one file (mi-stack.exp) until the MI version is bumped > > > up one number. Then mi-stack.exp could be renamed mi2-stack.exp and a new > > > file mi-stack.exp could be created. > > > > > > In reality GDB doesn't support more than one version of MI (the current > > > one). As has been shown on the mailing list recently, even MI output > > > from GDB 6.3 differs from MI output from GDB in CVS. > > > > mi2 is a released protocol; the intent is that we not make > > backwards-incompatible changes to mi2-*.exp, at least not without > > paying close attention to them. -i=mi sets mi_version to 3 today. > > Until we're ready to declare mi3 usable, we need to continue caring > > about mi2. > > -i=mi sets mi_version to 2 in my copy: > > interp_add (interp_new (INTERP_MI, NULL, mi_out_new (2), &procs)); > > and > > if (current_interp_named_p (INTERP_MI1)) > deprecated_command_loop_hook = mi1_command_loop; > else if (current_interp_named_p (INTERP_MI2)) > deprecated_command_loop_hook = mi2_command_loop; > else if (current_interp_named_p (INTERP_MI3)) > deprecated_command_loop_hook = mi3_command_loop; > else > deprecated_command_loop_hook = mi2_command_loop; > > > As far as I can see mi3 does nothing that mi2 doesn't do. I think the ideology is that mi3 is allowed to change in such a way that mi2 is not. So, all new features go into mi3, while mi2 should remain stable and unchanged, except for bug fixes and minor new improvements that are backwards compatible. Bob Rossi