From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14818 invoked by alias); 29 Mar 2006 23:40:47 -0000 Received: (qmail 14810 invoked by uid 22791); 29 Mar 2006 23:40:47 -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, 29 Mar 2006 23:40:45 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FOkHJ-0003Js-I4; Wed, 29 Mar 2006 18:40:41 -0500 Date: Thu, 30 Mar 2006 09:49:00 -0000 From: Daniel Jacobowitz To: Paul Brook Cc: gdb-patches@sourceware.org Subject: Re: mi-until.exp failures Message-ID: <20060329234041.GE9916@nevyn.them.org> Mail-Followup-To: Paul Brook , gdb-patches@sourceware.org References: <200603031503.50340.paul@nowt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603031503.50340.paul@nowt.org> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00353.txt.bz2 On Fri, Mar 03, 2006 at 03:03:50PM +0000, Paul Brook wrote: > I'm seeing the following failures on arm-none-eabi with a gcc4.x compiler: > > FAIL: gdb.mi/mi-until.exp: until after while loop (timeout) > FAIL: gdb.mi/mi2-until.exp: until after while loop (timeout) > > Turns out that this the "until" command actuig in unexpected ways, as > described in this thread: > http://sources.redhat.com/ml/gdb/2005-02/msg00151.html > > AFAICS there's not been any real consensus whether this is a bug or a feature. > I've had a quick look at making the command work purely on source lines, > and concluded I don't have the time/inclination to make it work. I just want > to squish the unexpected testsuite failure. I see that I never responded to Eli last February; lo and behold, it's two of the 528 new messages in my gdb@ folder. Shame on me. I just went through until_next_command and next_command/step_1 line by line. The current implementation of until_next_command is similar to "next", except that the stepping range is from the start of the function to the current PC; so it is clearly "step until a higher PC" [I had to look a couple of times to figure out how it worked]. It's been that way since before the dawn of recorded cvs annotate. Here's what the documentation actually says: Continue running until a source line past the current line, in the current stack frame, is reached. This command is used to avoid single stepping through a loop more than once. It is like the `next' command, except that when `until' encounters a jump, it automatically continues execution until the program counter is greater than the address of the jump. This means that when you reach the end of a loop after single stepping though it, `until' makes your program continue execution until it exits the loop. In contrast, a `next' command at the end of a loop simply steps back to the beginning of the loop, which forces you to step through the next iteration. The first two sentences agree with the testcase. The next sentence describes what is actually implemented. The second paragraph concludes that the two are equivalent. This was clearly the case in a previous generation of compilers, but it isn't any more. So: > b) Decide this is a bug. I will file a bug and kfail the testcase. > > Ok? PASS or KFAIL? > 2006-03-03 Paul Brook > > * gdb.mi/mi-until.exp: kfail broken until command. > * gdb.mi/mi2-until.exp: Ditto. I'll approve this one. It's actually in the test_until function, by the way. It's a bug; it would be nice if someone fixed it, but infrun may need some care and attention first. -- Daniel Jacobowitz CodeSourcery