From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9938 invoked by alias); 10 Jan 2007 20:23:32 -0000 Received: (qmail 9930 invoked by uid 22791); 10 Jan 2007 20:23:31 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 10 Jan 2007 20:23:26 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H4jyj-0003O0-8i; Wed, 10 Jan 2007 15:23:21 -0500 Date: Wed, 10 Jan 2007 20:23:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: MI testsuite failures [PATCH] Message-ID: <20070110202321.GA12861@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com 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> <17828.37170.793413.362882@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17828.37170.793413.362882@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00293.txt.bz2 On Wed, Jan 10, 2007 at 08:09:38PM +1300, Nick Roberts wrote: > 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. Running a single .exp file for multiple MI interpreters would be a bit tricky, but we could probably do it. You'd have to wrap most of them in a function and call it twice, I guess. I don't feel strongly about this if you want to change it. > 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. I haven't thought about it much. They'll appear at least one release before we change -i=mi though. > Hmm, what is this incompatible change anyway? Quoting. I posted an analysis of command line quoting issues to the gdb list around the middle of last year; I intend to make every single MI command handle quoting the way the manual says MI ought to, but this will change the behavior of various commands (the directory and file related ones, mainly, but -gdb-set will probably be affected too). -- Daniel Jacobowitz CodeSourcery