From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2946 invoked by alias); 10 Apr 2008 21:12:46 -0000 Received: (qmail 2887 invoked by uid 22791); 10 Apr 2008 21:12:42 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Apr 2008 21:12:14 +0000 Received: (qmail 14558 invoked from network); 10 Apr 2008 21:12:12 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Apr 2008 21:12:12 -0000 From: Pedro Alves To: luisgpm@linux.vnet.ibm.com Subject: Re: MI testsuite fix Date: Thu, 10 Apr 2008 22:10:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sourceware.org References: <200804102102.07722.pedro@codesourcery.com> <1207859802.9173.15.camel@gargoyle> In-Reply-To: <1207859802.9173.15.camel@gargoyle> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804102212.21028.pedro@codesourcery.com> 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: 2008-04/txt/msg00209.txt.bz2 A Thursday 10 April 2008 21:36:42, Luis Machado escreveu: > There is an additional failure in the MI testsuite (PPC) when running in > asynch mode, mi-simplerun.exp and mi2-simplerun.exp, which seems to be > an output ordering issue as well. > > "Correct" output: > 220-exec-continue^M > 220^running^M > (gdb) ^M > Hello, World!callme^M > callme^M > 220*stopped,reason="exited-normally"^M > (gdb) ^M > PASS: gdb.mi/mi-simplerun.exp: continue to end > > "Incorrect" output: > 220-exec-continue^M > 220^running^M > Hello, World!callme^M > callme^M > (gdb) ^M > FAIL: gdb.mi/mi-simplerun.exp: continue to end (failed to resume) > > Correct and incorrect between "" because both ending results are valid. > > This is not fixed by your latest patch, Pedro. What do you think? > Ah, this is the one I had already analized here: http://sourceware.org/ml/gdb-patches/2008-03/msg00293.html The issue is that there is a race between gdb printing (gdb) and the inferior starting to print too. In sync mode, you don't see it, because ^running and (gdb) and output before starting the target: fputs_unfiltered ("^running\n", raw_stdout); fputs_unfiltered ("(gdb) \n", raw_stdout); I don't know if the protocol specifies when is it that a frontend should expect that the inferior starts outputing to the console. (gdb) should mean GDB is ready for input, not that the inferior started, right? Maybe GDB should wait for a *running notification instead of (GDB), but even so, I'm not sure every target will emit it in single-threaded programs. So, to me this looks like a testsuite deficiency. Perhaps we should just put a sleep (1) at the start of that test. -- Pedro Alves