From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32214 invoked by alias); 12 Jan 2009 03:11:59 -0000 Received: (qmail 32204 invoked by uid 22791); 12 Jan 2009 03:11:58 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_05,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Jan 2009 03:11:18 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n0C3Fxja018251; Sun, 11 Jan 2009 21:15:59 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Jan 2009 21:11:02 -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: Mon, 12 Jan 2009 03:11:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BEED@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BEC8@ecamlmw720.eamcs.ericsson.se><18757.63035.269334.203651@kahikatea.snap.net.nz><6D19CA8D71C89C43A057926FE0D4ADAA04E1BED4@ecamlmw720.eamcs.ericsson.se> <18761.60118.104115.85983@kahikatea.snap.net.nz> From: "Marc Khouzam" To: "Nick Roberts" Cc: "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: 2009-01/txt/msg00053.txt.bz2 Volodya, any opinion on this? I could switch to async mode to solve this problem, but I'm hesitant to do so because it may have side-effects to DSF-GDB that I may not be aware of. Except for this bug, I'm not too sure on the advantages of async-mode for DSF-GDB. So, if you feel this bug can be fixed, I will probably wait for the fix, instead of risking going to async-mode. Thanks for your input Marc -----Original Message----- From: Nick Roberts [mailto:nickrob@snap.net.nz] Sent: Thu 12/18/2008 1:16 AM To: Marc Khouzam Cc: Vladimir Prus; gdb@sources.redhat.com Subject: RE: Re: MI *stopped event with CLI commands =20 > > set target-async on > >=20 > > first, you do get the full information. Perhaps this should be the de= fault > > for targets which can run asynchronously. >=20 > Vladimir Prus wrote: > > > > Probably. Though it does not change the fact that *stopped without det= ails > > sounds like a bug. I'll take a look, though it might take a few days. >=20 > I looked into the fact that *stopped worked properly with async on but n= ot > with async off (thanks Nick.) My understanding of GDB internals is quite > limited, but I believe what is happening is the following: >=20 > 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. S= o, > after the inferior is resumed, we should probably go back to the MI uiou= t. >... 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. --=20 Nick http://www.inet.net.nz/~nick= rob