From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14222 invoked by alias); 28 Jun 2008 05:49:30 -0000 Received: (qmail 14209 invoked by uid 22791); 28 Jun 2008 05:49:29 -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; Sat, 28 Jun 2008 05:49:06 +0000 Received: (qmail 4272 invoked from network); 28 Jun 2008 05:49:04 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Jun 2008 05:49:04 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI/RFC] Emit ^running via observer. Date: Sat, 28 Jun 2008 09:41:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sources.redhat.com References: <200806140108.24047.vladimir@codesourcery.com> <200806270829.53537.vladimir@codesourcery.com> <18533.33379.962529.54094@kahikatea.snap.net.nz> In-Reply-To: <18533.33379.962529.54094@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: <200806280949.09304.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/msg00528.txt.bz2 On Saturday 28 June 2008 04:14:27 Nick Roberts wrote: > > > 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? > > Async mode decouples the output from the input. This allows a CLI command that > executes the inferior to (indirectly) generate MI output. That's why I was > interested in async mode and that's what this test is for. The work has > actually been done for more general reasons, such as non-stop mode. I think > the MI output is just a fortunate side-effect. Err, async mode does one thing -- allows commands to be processed while inferiour is still running. Unless you explicitly make use of this functionality, there's no difference from sync mode. (Of course, there's a bunch of checks for target_can_async_p in GDB code, so some difference in output is possible, but in theory there should be none). I don't know what you mean by decoupling output from the input -- for example, then *running notification is emitted for CLI just fine, and this does not require async mode. > >... > > > 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. > > Maybe that's a requirement of non-stop mode but I'm not sure that this is > relevant here, i.e. with just async mode. I meant relative complexity of things. Making the thread list always have a single thread is relatively straight-forward, but still, making this happen for *all* targets is going to take lots of time. Adding async support for a target is considerably harder -- as linux-nat.c changes clearly demonstrate. Therefore, I don't expect that GDB will support async on a wide set of targets anytime soon. - Volodya