From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17974 invoked by alias); 18 Dec 2008 06:17:53 -0000 Received: (qmail 17964 invoked by uid 22791); 18 Dec 2008 06:17:52 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.23) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 06:17:00 +0000 Received: from kahikatea.snap.net.nz (176.63.255.123.dynamic.snap.net.nz [123.255.63.176]) by viper.snap.net.nz (Postfix) with ESMTP id A3C143DA4F9; Thu, 18 Dec 2008 19:16:56 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 497908FC6D; Thu, 18 Dec 2008 19:16:55 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18761.60118.104115.85983@kahikatea.snap.net.nz> Date: Thu, 18 Dec 2008 06:17:00 -0000 To: "Marc Khouzam" Cc: "Vladimir Prus" , Subject: RE: Re: MI *stopped event with CLI commands In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BED4@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BEC8@ecamlmw720.eamcs.ericsson.se> <18757.63035.269334.203651@kahikatea.snap.net.nz> <6D19CA8D71C89C43A057926FE0D4ADAA04E1BED4@ecamlmw720.eamcs.ericsson.se> 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/msg00075.txt.bz2 > > set target-async on > > > > first, you do get the full information. Perhaps this should be the default > > for targets which can run asynchronously. > > Vladimir Prus wrote: > > > > Probably. Though it does not change the fact that *stopped without details > > 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 > limited, but I believe what is happening is the following: > > When issuing a command that resumes the inferior, say -exec-continue or > continue, we eventually end up in method proceed(...) of infrun.c On the > call chain to that method, if the 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 to me 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 probably go back to the MI uiout. >... I imagine that you can get MI-like output from a CLI execution command by switching uiout at critical places but asynchronous mode seems to me to be the natural way to do it as it decouples GDB output from the command that started the execution, be it MI or CLI. -- Nick http://www.inet.net.nz/~nickrob