From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12784 invoked by alias); 18 Dec 2008 03:30:34 -0000 Received: (qmail 12775 invoked by uid 22791); 18 Dec 2008 03:30:33 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 03:29:48 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id mBI3Tkf2011949; Wed, 17 Dec 2008 21:29:46 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 21:29:46 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Re: MI *stopped event with CLI commands Date: Thu, 18 Dec 2008 03:30:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BED4@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BEC8@ecamlmw720.eamcs.ericsson.se> <18757.63035.269334.203651@kahikatea.snap.net.nz> A From: "Marc Khouzam" To: "Vladimir Prus" , X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00074.txt.bz2 Nick Roberts wrote: >=20 > set target-async on >=20 > first, you do get the full information. Perhaps this should be the defau= lt > for targets which can run asynchronously. Vladimir Prus wrote: > > Probably. Though it does not change the fact that *stopped without detail= s sounds > like a bug. I'll take a look, though it might take a few days. I looked into the fact that *stopped worked properly with async on but not = with async off (thanks Nick.) My understanding of GDB internals is quite limite= d, but I believe what is happening is the following: When issuing a command that resumes the inferior, say -exec-continue or con= tinue, we eventually end up in method proceed(...) of infrun.c On the call chain to that method, if the=20 command that resumed the inferior was a CLI command (e.g. continue) the uiout structure has been forced to be the CLI uiout; this makes sense t= o me=20 since we want any output of the CLI command to be formatted as CLI output. However, once the inferior stops, the output that follows should no longer = be in CLI format, I believe. So, after the inferior is resumed, we should probab= ly go back=20 to the MI uiout. In async mode, this does happens because proceed(...) returns immediately a= nd everything gets undone nicely. But when async is off proceed(...) blocks with the cod= e: if (!target_can_async_p ()) { wait_for_inferior (0); normal_stop (); } Since normal_stop() is called directly from proceed(...) the uiout is still= set to CLI=20 in this case, and the information of the *stopped event is created in a CLI= format, which=20 explains why *stopped has no information. So, if I understood all this right, I think the uiout should be reset befor= e calling normal_stop(). I'm sure this is an over-simplification, but I hope it can = point in the right direction for this bug. Thanks Marc