From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 590 invoked by alias); 10 Aug 2005 00:48: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 571 invoked by uid 22791); 10 Aug 2005 00:48:32 -0000 Received: from eastrmmtao05.cox.net (HELO eastrmmtao05.cox.net) (68.230.240.34) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 10 Aug 2005 00:48:32 +0000 Received: from white ([68.9.64.121]) by eastrmmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050810004825.JZRV2947.eastrmmtao05.cox.net@white>; Tue, 9 Aug 2005 20:48:25 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1E2ele-00011G-00; Tue, 09 Aug 2005 20:48:26 -0400 Date: Wed, 10 Aug 2005 01:07:00 -0000 From: Bob Rossi To: Eli Zaretskii , Jim Ingham , gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20050810004826.GD3557@white> Mail-Followup-To: Eli Zaretskii , Jim Ingham , gdb-patches@sources.redhat.com References: <1123605445.30442.ezmlm@sources.redhat.com> <20050809181311.GB3012@white> <20050809223421.GB3557@white> <20050810004128.GA4264@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050810004128.GA4264@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-08/txt/msg00115.txt.bz2 On Tue, Aug 09, 2005 at 08:41:28PM -0400, Daniel Jacobowitz wrote: > On Tue, Aug 09, 2005 at 06:34:21PM -0400, Bob Rossi wrote: > > 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. > > But we haven't got all the relevant query commands, I think. And I > haven't a clue what the full set would be. Rather than adding them, > investing effort in getting the async approach going makes more sense > to me. I agree. However, getting the observer approach up and running, will in a way, define the full set. > As Jim's pointed out, you can need this any time you hit a breakpoint, > if the user has set commands on it. Keeping track of this in the FE is > going to be tricky. Also, if you're presenting a real console window > and you have to do a half-dozen queries after every command to keep the > UI up to date, that's probably going to be visibly slow. Here is another odd scenario, Jim, please give some info if you have experience in this area. If you hit a breakpoint, and the observer starts to send you data, does it - send all the state data in one async response, in the same response as the async MI command that says *stopped? - send all the state data in one async response, in a different response as the async MI command that says *stopped? - send all the state data, each in different async response's, in a different response as the async MI command that says *stopped? This may seem unimportant, however I believe it could be marginally important. For instance, does the front end have to wait for the async observer response before it can do anything else? Thanks, Bob Rossi