From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19523 invoked by alias); 10 Feb 2009 20:58:23 -0000 Received: (qmail 19512 invoked by uid 22791); 10 Feb 2009 20:58:22 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Feb 2009 20:58:14 +0000 Received: (qmail 17423 invoked from network); 10 Feb 2009 20:58:12 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Feb 2009 20:58:12 -0000 From: Vladimir Prus To: "Marc Khouzam" Subject: Re: [RFA] fix *stopped for CLI commands Date: Tue, 10 Feb 2009 20:58:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sources.redhat.com, "Nick Roberts" References: <200902061045.18508.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA06E84D64@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA06E84D64@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902102358.11736.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: 2009-02/txt/msg00227.txt.bz2 On Tuesday 10 February 2009 23:44:28 Marc Khouzam wrote: > > Vladimir Prus > > Sent: Friday, February 06, 2009 2:45 AM > > To: gdb-patches@sources.redhat.com; Nick Roberts; Marc Khouzam > > Subject: [RFA] fix *stopped for CLI commands > > > > This patch fixes this by making MI observer print frame > > again, into MI uiout, > > if necessary. > > I've applied the patch and tried it out. It works as expected > but it 'allowed' me to run into another problem. > > When issuing a CLI command that triggers a ^running event, > the token id is not part of the ^running event anymore. > You can see this in the summarized session below. > > 26-exec-run > [...] > 26^running <-- token is there for MI command > *running,thread-id="all" > (gdb) > [...] > (gdb) > 27run > &"run\n" > [...] > ^running <-- token is not there for CLI command > *running,thread-id="all" > (gdb) > > I never noticed this before because DSF-GDB never uses CLI commands > that would trigger a ^running. So, to DSF-GDB it looks like the > CLI command never completed. Why does DSF use tokens at all? I probably can fix this up, but I am not sure the tokens are really necessary. Does anybody envision a case where GDB would report command results out-of-order? - Volodya