From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24815 invoked by alias); 10 Mar 2005 15:13:25 -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 23916 invoked from network); 10 Mar 2005 15:12:41 -0000 Received: from unknown (HELO pluton.ispras.ru) (83.149.199.253) by sourceware.org with SMTP; 10 Mar 2005 15:12:41 -0000 Received: (qmail 8533 invoked from network); 10 Mar 2005 15:08:40 -0000 Received: from unknown (HELO truba.ispras.ru) (83.149.198.41) by pluton.ispras.ru with SMTP; 10 Mar 2005 15:08:40 -0000 Received: from truba.ispras.ru (root@localhost) by truba.ispras.ru (8.13.1/8.13.1) with SMTP id j2AF83a6002377 for ; Thu, 10 Mar 2005 18:08:03 +0300 Received: from ispserv.ispras.ru (ispserv [83.149.198.72]) by truba.ispras.ru (8.13.1/8.13.1) with ESMTP id j2AF83CT002367; Thu, 10 Mar 2005 18:08:03 +0300 Received: from ispserv.ispras.ru (localhost [127.0.0.1]) by ispserv.ispras.ru (8.12.8/8.12.8) with ESMTP id j2AF6DDA010551; Thu, 10 Mar 2005 18:06:13 +0300 Received: from localhost (kostik@localhost) by ispserv.ispras.ru (8.12.8/8.12.8/Submit) with ESMTP id j2AF6D5s010547; Thu, 10 Mar 2005 18:06:13 +0300 X-Authentication-Warning: ispserv.ispras.ru: kostik owned process doing -bs Date: Thu, 10 Mar 2005 15:13:00 -0000 From: Karganov Konstantin To: Bob Rossi cc: GDB Subject: Re: MI output command error In-Reply-To: <20050310144013.GB14061@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/msg00105.txt.bz2 > 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. I suppose that no one is going to change the existing behavior 444-exec-continue 444^running (gdb) 444*stopped (gdb) at least for historical reasons. And again - for uniformity with the human-oriented gdb output and the case of sharing the tty with inferior. If so, I suggest the following model of interaction with gdb: -> FE starts gdb and reads its output (there could be startup error msgs) -> FE sends a MI command and waits for its completion -> gdb sends a sequence of responses (there can be an automatic displays, for example. (oob_rec)* is really needed, there can be any number of the messages!) we are waiting for ^-response. if we get ^running (for execution commands) we start waiting for *stopped one. getting the response we always skip "(gdb)" line. Meanwhile the inferior tty works independently (in other thread/window of FE, for example). ANd it seems to me that making a FE over gdb you surely need to redirect the inferior I/O somewhere. Konstantin.