From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9195 invoked by alias); 27 Jun 2005 13:00:49 -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 9141 invoked by uid 22791); 27 Jun 2005 13:00:40 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 27 Jun 2005 13:00:40 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1DmtDy-0006cO-Cr; Mon, 27 Jun 2005 09:00:30 -0400 Date: Mon, 27 Jun 2005 13:00:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Mark Kettenis , gdb@sourceware.org Subject: Re: MI-related testsuite regressions Message-ID: <20050627130030.GA10394@nevyn.them.org> Mail-Followup-To: Nick Roberts , Mark Kettenis , gdb@sourceware.org References: <200506270815.j5R8FZO6026261@jop31.nfra.nl> <17087.60064.541364.938844@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17087.60064.541364.938844@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00256.txt.bz2 On Tue, Jun 28, 2005 at 12:01:36AM +1200, Nick Roberts wrote: > > I see a fair number of new testsuite regressions: > > > > -PASS: gdb.mi/mi2-stack.exp: stack select same frame > > +FAIL: gdb.mi/mi2-stack.exp: stack select same frame > > Yes. These are due to my changes. I'm going to echo Mark here. I assumed that you would not post a patch which introduced failures in the testsuite. > 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. You removed the parallel to this failing test from mi-stack.exp; I assume it should be removed from mi2-stack.exp also? > > -PASS: gdb.mi/mi2-var-block.exp: step at do_block_test > > -PASS: gdb.mi/mi2-var-block.exp: create local variable foo2 > > +FAIL: gdb.mi/mi2-var-block.exp: step at do_block_test (stopped at wrong place) > > +FAIL: gdb.mi/mi2-var-block.exp: create local variable foo2 > > > > -PASS: gdb.mi/mi2-var-block.exp: step at do_block_test > > +FAIL: gdb.mi/mi2-var-block.exp: step at do_block_test (stopped at wrong place) > > > > -PASS: gdb.mi/mi2-var-block.exp: step at do_block_test > > +FAIL: gdb.mi/mi2-var-block.exp: step at do_block_test (stopped at wrong place) > > > > -PASS: gdb.mi/mi2-var-block.exp: update cb > > +FAIL: gdb.mi/mi2-var-block.exp: update cb > > > > -PASS: gdb.mi/mi2-var-block.exp: delete var foo2 > > +FAIL: gdb.mi/mi2-var-block.exp: delete var foo2 > > > They seem all to be related to your recent changes. > > I can't see how these relate to my changes. I have submitted a patch for > variable objects, but it still hasn't been approved. I don't understand why > mi-var-block.exp doesn't fail at the same places. Mark, could you post a bit of gdb.log? I don't see these. -- Daniel Jacobowitz CodeSourcery, LLC