From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14323 invoked by alias); 10 Mar 2005 09:33:09 -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 14238 invoked from network); 10 Mar 2005 09:33:02 -0000 Received: from unknown (HELO pluton.ispras.ru) (83.149.199.253) by sourceware.org with SMTP; 10 Mar 2005 09:33:02 -0000 Received: (qmail 98656 invoked from network); 10 Mar 2005 09:29:00 -0000 Received: from unknown (HELO truba.ispras.ru) (83.149.198.41) by pluton.ispras.ru with SMTP; 10 Mar 2005 09:29:00 -0000 Received: from truba.ispras.ru (root@localhost) by truba.ispras.ru (8.13.1/8.13.1) with SMTP id j2A9SO2r010893 for ; Thu, 10 Mar 2005 12:28:24 +0300 Received: from ispserv.ispras.ru (ispserv [83.149.198.72]) by truba.ispras.ru (8.13.1/8.13.1) with ESMTP id j2A9SOIG010887 for ; Thu, 10 Mar 2005 12:28:24 +0300 Received: from kite.ispras.ru (kite.ispras.ru [83.149.198.52]) by ispserv.ispras.ru (8.12.8/8.12.8) with ESMTP id j2A9QXDA002538 for ; Thu, 10 Mar 2005 12:26:33 +0300 Date: Thu, 10 Mar 2005 09:33:00 -0000 From: Konstantin Karganov Reply-To: Konstantin Karganov Organization: ISP RAS Message-ID: <446808079.20050310123642@ispras.ru> To: GDB Subject: Re[2]: MI output command error In-reply-To: <20050309232239.GB12792@white> References: <20050309023957.GB10866@white> <20050309232239.GB12792@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00096.txt.bz2 Hello Bob, > There is no way 1 MI input command can result in more than one MI output > commands. The front end would probably send 1 command, after it got back > the first "(gdb)", and then send another command for the second time. > This would cause the front end's buffer to get out of sync with GDB. > If anyone think's that this is not a problem, please let me know why. I think that is not a problem. Look, in MI specification there are special records for status-async-output ("information about the progress of slow operation") and notify-async-output ("supplementary information that the client should handle"). From these descriptions it is clearly possible, that this records can be multiple (say, a progress of a very slow operation :) ) plus the result-record for the command. Another similar hint is that there are (oob-record)* in output rule. Though it doesn't make several messages now, who knows all the use cases and how it will behave in the next versions... For myself, I decided to ignore "(gdb)" strings and wait for the appropriate result-record (it will always appear, according to grammar), collecting passing async-records at the same time. I suppose that the only way to get in line with GDB responses is to keep track of message tokens. And implementing the GUI frontend you will have to use tokens anyhow. -- Best regards, Konstantin