From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-20879-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 16123 invoked by alias); 10 Mar 2005 15:52:37 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 15891 invoked from network); 10 Mar 2005 15:52:25 -0000
Received: from unknown (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68)
  by sourceware.org with SMTP; 10 Mar 2005 15:52:25 -0000
Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.7.1]); Thu, 10 Mar 2005 15:08:17 +0000
Received: from mace ([192.168.1.25]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.211);
	 Thu, 10 Mar 2005 15:08:04 +0000
From: "Dave Korn" <dave.korn@artimi.com>
To: "'Bob Rossi'" <bob@brasko.net>,
	"'Karganov Konstantin'" <kostik@ispras.ru>
Cc: "'GDB'" <gdb@sources.redhat.com>
Subject: RE: MI output command error
Date: Thu, 10 Mar 2005 15:52:00 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20050310144013.GB14061@white>
Message-ID: <SERRANOyz5b6KZmcK8r00000026@SERRANO.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 10 Mar 2005 15:08:04.0893 (UTC) FILETIME=[F5C064D0:01C52582]
X-SW-Source: 2005-03/txt/msg00106.txt.bz2

----Original Message----
>From: Bob Rossi
>Sent: 10 March 2005 14:40

> 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"

  Your imagination unfortunately fails to correspond to reality.  This is
*your* fault, not reality's.  What part of "asynchronous" don't you
understand?

> That's why I think the output
> 
>    (gdb)
>    444-exec-continue
>    444*running
>    444*stopped...
>    (gdb)
> 
> is better.

  Well, you're wrong.  "running" is the output from the exec-continue
command and it is synchronous: the exec-continue command executes, starts up
the inferior, prints out "running", and is then complete.  At that point the
inferior is running, but regardless of that, gdb is ready to take more
commands and so should prompt you.  The "stopped" output is an asynchronous
notification of an event that occurred while the inferior was running, but
that in no sense makes it output from the "exec-continue" command.  It can
occur spontaneously, it can happen sooner or later or not at all, and your
model of the interaction between FE and MI as being a completely predictable
one-command-one-reply set of exchanges is inaccurate, incomplete, and
inadequate to the task.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....