From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 929 invoked by alias); 26 Jun 2008 15:58:29 -0000 Received: (qmail 917 invoked by uid 22791); 26 Jun 2008 15:58:28 -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, 26 Jun 2008 15:58:10 +0000 Received: (qmail 31224 invoked from network); 26 Jun 2008 15:58:09 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Jun 2008 15:58:09 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI/RFC] Emit ^running via observer. Date: Thu, 26 Jun 2008 18:54:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sources.redhat.com References: <200806140108.24047.vladimir@codesourcery.com> <200806251835.08864.vladimir@codesourcery.com> <18531.2798.547630.806116@kahikatea.snap.net.nz> In-Reply-To: <18531.2798.547630.806116@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200806261958.06374.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-06/txt/msg00482.txt.bz2 On Thursday 26 June 2008 07:20:14 Nick Roberts wrote: > > I've checked in the following, which differs from original by extra test > > strictness. > > Thanks. > > > Further, I've converted mi-async.exp to use the helper > > functions. Nick, as it stands now it does not seem that mi-async.exp tests > > async behaviour at all -- it merely changes that we get ^running for CLI > > commands, and we get that in both sync and async mode. Do you think it > > worthwhile to rename the test or move its content somewhere else? > > The tests appear to fail now. Which tests? With unmodified CVS state, all MI tests pass for me both in sync and async mode. But indeed, if I make mi-async.exp not force async mode, it starts to fail.... > SYNC: > > r > &"r\n" > ~"Starting program: /home/nickrob/myprog \n" > =thread-created,id="1" > ^running > *running,thread-id="all" > (gdb) > ~"\n" > ~"Breakpoint 1, main (argc=1, argv=0xbf961424) at myprog.c:146\n" > ~"146\tmain (int argc, char **argv) {\n" > *stopped > (gdb) ... in this way. > i.e no reason, frame, file, etc fields. It's important for the console in a > frontend that the CLI command generates the same MI output as the corresponding > MI command. Of course. This is pre-existing problem, though, and was present in gdb 6.8 -- except that we did not output neither ^running nor *stopped at all -- so apparently making mi-async.exp not actually enable async mode is a bit premature yet. The problem, it appears, is that while the CLI command executes, 'uiout' is the CLI interpreter's uiout, not MI uiout. I'll probably won't have time to work on this in next month, so patches welcome. - Volodya