From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17441 invoked by alias); 10 Mar 2005 14:01:13 -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 17186 invoked from network); 10 Mar 2005 14:01:01 -0000 Received: from unknown (HELO lakermmtao10.cox.net) (68.230.240.29) by sourceware.org with SMTP; 10 Mar 2005 14:01:01 -0000 Received: from white ([68.9.64.121]) by lakermmtao10.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050310140055.TBGX29924.lakermmtao10.cox.net@white>; Thu, 10 Mar 2005 09:00:55 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1D9ODh-0003fw-00; Thu, 10 Mar 2005 09:00:57 -0500 Date: Thu, 10 Mar 2005 14:01:00 -0000 From: Bob Rossi To: Karganov Konstantin Cc: GDB Subject: Re: MI output command error Message-ID: <20050310140057.GA14061@white> Mail-Followup-To: Karganov Konstantin , GDB References: <20050310130544.GA13958@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/msg00101.txt.bz2 On Thu, Mar 10, 2005 at 04:36:59PM +0300, Karganov Konstantin wrote: > > > Yeah, but even using the TOKENS doesn't work. The problem is, whenver I > > front end get's a "(gdb)\r\n" it knows that it can send another command. > > When you use the tokens with this command, you end up with, > > > > (gdb) > > 444-exec-continue > > 444^running > > (gdb) > > 444*stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"} > > (gdb) > > > > This is still incorrect. The front end would have to know that the first > > MI output command was not the end of the output from the single MI > > input command. In other words, the FE would have to hardcode the fact > > that the -exec-continue command may output 2 MI output commands. This > > can't be correct, it would be better if the output is changed to, > > 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? Thanks, Bob Rossi