From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16055 invoked by alias); 10 Jan 2007 07:09:58 -0000 Received: (qmail 16043 invoked by uid 22791); 10 Jan 2007 07:09:57 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 Jan 2007 07:09:49 +0000 Received: from kahikatea.snap.net.nz (p202-124-120-214.snap.net.nz [202.124.120.214]) by viper.snap.net.nz (Postfix) with ESMTP id 577123D8384; Wed, 10 Jan 2007 20:09:41 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 7C0B04F6C5; Wed, 10 Jan 2007 20:09:40 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17828.37170.793413.362882@kahikatea.snap.net.nz> Date: Wed, 10 Jan 2007 07:09:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: MI testsuite failures [PATCH] In-Reply-To: <20070109225048.GM30631@nevyn.them.org> References: <17825.33653.885121.321357@kahikatea.snap.net.nz> <17825.56391.466504.569955@kahikatea.snap.net.nz> <20070108171149.GC15412@nevyn.them.org> <17826.50865.340113.767106@kahikatea.snap.net.nz> <20070108224526.GA28903@nevyn.them.org> <17826.54122.891164.154788@kahikatea.snap.net.nz> <20070109142623.GA17931@nevyn.them.org> <17828.5284.347590.450036@kahikatea.snap.net.nz> <20070109225048.GM30631@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.92.8 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00291.txt.bz2 > > That's why I've raised it again. There are still no features unique to > > mi3 and I thought perhaps that enough time has elapsed to reconsider it. > > *shrug* > > I am still planning to add at least one incompatible change for mi3, > once I finally get around to it. I'd just have to add all the files > back again. So they're useful to me; if they're too much trouble, > I'll offer to update them myself. This doesn't seem a sensible way to do it as eventually we'll have massive duplication (multiplication?). Note that the manual claims that GDB supports mi1 but there don't appear to be any tests for it. I think: 1) mi-*exp should be tests that work for all mi`N' where N > 1, and could be run for each MI interpreter. 2) mi2-*exp tests that work for mi2 but fail for mi3, currently none. 3) mi3-*exp tests that work for mi3 but fail for mi2, currently none. Also if mi3 becomes the new mi, we presumably should advise frontend developers to specify mi2, otherwise existing frontends might get a nasty surprise when the new features of mi3 appear. Hmm, what is this incompatible change anyway? -- Nick http://www.inet.net.nz/~nickrob