From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27812 invoked by alias); 5 May 2008 08:41:10 -0000 Received: (qmail 27804 invoked by uid 22791); 5 May 2008 08:41:09 -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; Mon, 05 May 2008 08:40:51 +0000 Received: (qmail 26898 invoked from network); 5 May 2008 08:40:49 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 May 2008 08:40:49 -0000 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: Fix MI/async testsuite Date: Mon, 05 May 2008 09:15:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sourceware.org References: <200805041618.14962.vladimir@codesourcery.com> <200805042138.02094.vladimir@codesourcery.com> <20080504195640.GA15966@caradoc.them.org> In-Reply-To: <20080504195640.GA15966@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805051240.48055.vladimir@codesourcery.com> 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-05/txt/msg00195.txt.bz2 On Sunday 04 May 2008 23:56:40 Daniel Jacobowitz wrote: > On Sun, May 04, 2008 at 09:38:01PM +0400, Vladimir Prus wrote: > > Well, ideally, ^running should not exist. When gdb is done with a command, > > it should always print ^done, and since it's done with a command, print a > > prompt. Unfortunately, right now ^running exists and does something fairly > > strange: > > > > - in sync mode, you get "^running" + "(gdb)" before even trying to resume > > target > > - in async mode you get "^running" + random output + "(gdb)" > > - in async mode when running CLI command, you get "^running" + "^done" > > > > This is a mess, but I don't think we should/can fix this mess without > > going to MI3. > > For MI2, why can't we leave ^running We can't "leave" it, because in async mode ^running is not immediately followed by a prompt, now, and before any my changes. > always followed by a prompt? We > fail to accept input at that prompt in sync mode, which is a known > bug, but that's life. I sure can make all ^running be followed by prompt, but that would be "fixing" code to be as buggy as the other code. Does it worth the time? > I don't think having ^result followed by =EVENT followed by (gdb) > makes sense, I think it does -- and the MI spec I've just posted explicitly calls for such behaviour for run commands: 1. First you get ^done, which means "Okay, nothing else to do about this command" 2. Then you get *running, =whatever, ..., *stopped In async mode, you get prompt immediately after (1) -- because it's where gdb is ready to accept commands. In sync mode, you get prompt after (2). Of course, we can print ^done only after (2) in that case, but does it make sense? - Volodya