From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6441 invoked by alias); 9 Aug 2005 22:34:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6432 invoked by uid 22791); 9 Aug 2005 22:34:27 -0000 Received: from eastrmmtao01.cox.net (HELO eastrmmtao01.cox.net) (68.230.240.38) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 09 Aug 2005 22:34:27 +0000 Received: from white ([68.9.64.121]) by eastrmmtao01.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050809223420.DQDQ12912.eastrmmtao01.cox.net@white>; Tue, 9 Aug 2005 18:34:20 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1E2cft-0000we-00; Tue, 09 Aug 2005 18:34:21 -0400 Date: Wed, 10 Aug 2005 00:41:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: Jim Ingham , gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20050809223421.GB3557@white> Mail-Followup-To: Eli Zaretskii , Jim Ingham , gdb-patches@sources.redhat.com References: <1123605445.30442.ezmlm@sources.redhat.com> <20050809181311.GB3012@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2005-08/txt/msg00111.txt.bz2 On Tue, Aug 09, 2005 at 10:27:34PM +0300, Eli Zaretskii wrote: > > Date: Tue, 9 Aug 2005 14:13:11 -0400 > > From: Bob Rossi > > Cc: Jim Ingham , gdb-patches@sources.redhat.com > > > > > I thought we wanted to have _both_ CLI and MI style response in this > > > case: the CLI response to display in the command buffer, the MI > > > response to be caught by the front end in order to change the display > > > in other windows. Am I missing something? > > > > Yes, this sounds nice to me. Currently, querying GDB/MI's state, via an > > MI function allows this, without any modifications to GDB/MI. > > How would the FE know that it needs to query the state? Isn't that > the problem? Eli, don't get me wrong. I fully support the observer approach, especially from what Jim has said. However, in the meantime, I think it's possible to query the state of GDB at any moment. So, if you allow the user to enter a command via -interpreter-exec console, you could then follow that command up with other MI commands to sync the state of GDB with the state of the FE. The problem is, commands like "are you still running?" defiantly carry a race condition along with them. Bob Rossi