From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25101 invoked by alias); 10 Mar 2005 13:43:33 -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 25026 invoked from network); 10 Mar 2005 13:43:27 -0000 Received: from unknown (HELO pluton.ispras.ru) (83.149.199.253) by sourceware.org with SMTP; 10 Mar 2005 13:43:27 -0000 Received: (qmail 5803 invoked from network); 10 Mar 2005 13:39:26 -0000 Received: from unknown (HELO truba.ispras.ru) (83.149.198.41) by pluton.ispras.ru with SMTP; 10 Mar 2005 13:39:26 -0000 Received: from truba.ispras.ru (root@localhost) by truba.ispras.ru (8.13.1/8.13.1) with SMTP id j2ADcoCP028281 for ; Thu, 10 Mar 2005 16:38:50 +0300 Received: from ispserv.ispras.ru (ispserv [83.149.198.72]) by truba.ispras.ru (8.13.1/8.13.1) with ESMTP id j2ADcoZo028271; Thu, 10 Mar 2005 16:38:50 +0300 Received: from ispserv.ispras.ru (localhost [127.0.0.1]) by ispserv.ispras.ru (8.12.8/8.12.8) with ESMTP id j2ADb0DA008445; Thu, 10 Mar 2005 16:37:00 +0300 Received: from localhost (kostik@localhost) by ispserv.ispras.ru (8.12.8/8.12.8/Submit) with ESMTP id j2ADb0hV008441; Thu, 10 Mar 2005 16:37:00 +0300 X-Authentication-Warning: ispserv.ispras.ru: kostik owned process doing -bs Date: Thu, 10 Mar 2005 13:43:00 -0000 From: Karganov Konstantin To: Bob Rossi cc: GDB Subject: Re: MI output command error In-Reply-To: <20050310130544.GA13958@white> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Spamtest-Info: Pass through X-SW-Source: 2005-03/txt/msg00100.txt.bz2 > 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. In GDB the execution commands behave like this - you get a confirmation (^running) when the execution has started (at this time the command is assumed to be accomplished) and you get the notification on inferior state change some time later (*stopped). So, working over MI you need to handle all execution commands in a way, that assumes "^running" as a beginning of execution and waits for "*stopped" for execution end. That's all. On the other hand, it would be more logical if the execution commands were considered accomplished only after execution completion (i.e. *running and ^stopped), but I think there was a reason to choose the way it was actually implemented. Konstantin. PS. all this resembles a group of savages, gathered around something unusual and discussing what could it be used for and guessing what it actually is... :)