From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30495 invoked by alias); 27 Jun 2008 04:30:14 -0000 Received: (qmail 30481 invoked by uid 22791); 27 Jun 2008 04:30:13 -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; Fri, 27 Jun 2008 04:29:56 +0000 Received: (qmail 25767 invoked from network); 27 Jun 2008 04:29:54 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Jun 2008 04:29:54 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI/RFC] Emit ^running via observer. Date: Fri, 27 Jun 2008 11:58:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sources.redhat.com References: <200806140108.24047.vladimir@codesourcery.com> <200806261958.06374.vladimir@codesourcery.com> <18532.12506.972674.635614@kahikatea.snap.net.nz> In-Reply-To: <18532.12506.972674.635614@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806270829.53537.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/msg00491.txt.bz2 On Friday 27 June 2008 04:14:18 Nick Roberts wrote: > > > The tests appear to fail now. > > > > Which tests? > > All three in mi-async.exp, at the moment. I'll look at them more closely to > see if they are due to local changes. > > > 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.... > > mi-async.exp is a test for async mode, so is not expected to pass in sync mode. That's the question -- what about this test is specific to async mode? > > > 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. > > It's not a problem if async mode becomes the default, which is my > understanding. Not mine, unfortunately. We can't even make all target always have at least one element in thread list -- which is much simpler change. - Volodya