From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7989 invoked by alias); 22 Sep 2004 15:01:50 -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 7982 invoked from network); 22 Sep 2004 15:01:49 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 22 Sep 2004 15:01:49 -0000 Received: from indel.ch (217-162-27-127.dclient.hispeed.ch [217.162.27.127]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with SMTP id i8MF1lmd001333 for ; Wed, 22 Sep 2004 17:01:48 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Wed, 22 Sep 2004 16:59:03 +0200 Message-Id: <5.2.0.9.1.20040922165511.01d57000@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Wed, 22 Sep 2004 15:01:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: MI rules In-Reply-To: <20040922144311.GB26132@white> References: <5.2.0.9.1.20040922155506.01d24ab8@NT_SERVER> <5.2.0.9.1.20040922153212.01d6bb38@NT_SERVER> <5.2.0.9.1.20040922153212.01d6bb38@NT_SERVER> <5.2.0.9.1.20040922155506.01d24ab8@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-09/txt/msg00183.txt.bz2 >> How are the existing frontends doing it then? Do they just wait after >> a sent command until they receive a reply and take it as the one they're >> looking for? > >Well part of the problem I see is with asyncrhonous MI output commands. That's the main problem I'd say. If the whole communication was synchronous you'd exactly know what answer is coming and not need any labeling. >How is the front end supposed to understand what the data it just >recieved was. It doesn't even know what type of mi output command it is. >So, after it is parsed and put in a parse tree, I don't see a >way for the front end to say, "Get the data out of this command that I >care about". It first needs to understand what type of mi output command >it just recieved. If it knows that, it can actually walk the parse tree >to get the data it needs. I was just wondering what commands you're parsing after looking into mi/mi-cmds.c. Am I seeing right that over half of the mi commands are not implemented yet? >Otherwise if it doesn't know that, you end up in a situation where you > 1. parse the tree. > 2. walk the tree to guess what kind of command you just received > ( can only imagine what kind of maintenence nightmare this is ) > 3. actually walk the tree to get the data you need, once you know > what kind of mi output command you have. > >This ends up making the parse walk the tree twice. IMO, GDB already >knows what kind of MI output command it is sending, so it should just >tell the front end as part of the mi output command. This would solve >several problems that I am facing. Yeah, a simple ^done can come from a lot of commands :) Thanks bye Fabi