From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11756 invoked by alias); 10 Mar 2005 14:40:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11515 invoked from network); 10 Mar 2005 14:40:15 -0000 Received: from unknown (HELO lakermmtao06.cox.net) (68.230.240.33) by sourceware.org with SMTP; 10 Mar 2005 14:40:15 -0000 Received: from white ([68.9.64.121]) by lakermmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050310144011.UTYC21504.lakermmtao06.cox.net@white>; Thu, 10 Mar 2005 09:40:11 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1D9Oph-0003hO-00; Thu, 10 Mar 2005 09:40:13 -0500 Date: Thu, 10 Mar 2005 14:40:00 -0000 From: Bob Rossi To: Karganov Konstantin Cc: GDB Subject: Re: MI output command error Message-ID: <20050310144013.GB14061@white> Mail-Followup-To: Karganov Konstantin , GDB References: <20050310140057.GA14061@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-03/txt/msg00103.txt.bz2 On Thu, Mar 10, 2005 at 05:06:35PM +0300, Karganov Konstantin wrote: > > > > If I were the GDB maintainer, I'd answer the following: > > > All "execution" commands (continue, step, next, etc) are partially > > > asynchronous - in the sence that when the execution is started you can > > > type a characters to inferior stdin. In this case you need a way to know > > > when the inferior starts/stops execution. > > > > Are you suggesting that you are using the MI with putting the inferior > > on a separate pty? > > I suppose, that it is implemented in the same way. I mean that redirection > of inferior's I/O makes just redirection and doesnt affect the way in > which gdb command processing is done. > > And it should be independent of tty redirection! > You will be scolding first if after using "tty" command the > ^running/*stopped will change to *running/^stopped... :) haha :) No, seriously though. Here is how I imagine a transaction between a FE and GDB. -> GDB alerts FE it is ready for a command via "(gdb)\r\n" -> FE sends a single MI input command -> FE does I/O with inferior -> GDB sends an MI output command -> GDB alerts FE it is ready for a command via "(gdb)\r\n" So, the only time a FE would know that it is ready to send a command is when it reaches the "(gdb)". Is this the same model for you? That's why I think the output (gdb) 444-exec-continue 444*running 444*stopped... (gdb) is better. Thanks, Bob Rossi