From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29295 invoked by alias); 22 Sep 2004 14:43:18 -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 29272 invoked from network); 22 Sep 2004 14:43:12 -0000 Received: from unknown (HELO lakermmtao08.cox.net) (68.230.240.31) by sourceware.org with SMTP; 22 Sep 2004 14:43:12 -0000 Received: from white ([68.9.64.121]) by lakermmtao08.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20040922144312.DYMF7122.lakermmtao08.cox.net@white>; Wed, 22 Sep 2004 10:43:12 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CA8Kt-0006r8-00; Wed, 22 Sep 2004 10:43:11 -0400 Date: Wed, 22 Sep 2004 14:43:00 -0000 From: Bob Rossi To: Fabian Cenedese Cc: gdb@sources.redhat.com, cagney@redhat.com, ezannoni@redhat.com, fnasser@redhat.com Subject: Re: MI rules Message-ID: <20040922144311.GB26132@white> Mail-Followup-To: Fabian Cenedese , gdb@sources.redhat.com, cagney@redhat.com, ezannoni@redhat.com, fnasser@redhat.com References: <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 Content-Disposition: inline In-Reply-To: <5.2.0.9.1.20040922155506.01d24ab8@NT_SERVER> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-09/txt/msg00180.txt.bz2 On Wed, Sep 22, 2004 at 04:05:33PM +0200, Fabian Cenedese wrote: > > >I currently have a set of rules that parse an MI output command. This > >includes the flex file, the bison file and an extra source file that > >populates an in memory data structure representing the MI output > >command. > > > >The rules from the documentation had to change only slightly to conform > >to what GDB is actually outputting. The problem is, I haven't tested the > >parser extensively. The reason for this is because I am waiting to here > >from the GDB developers how to interpret the data semantically once it > >is acquired. I believe that every MI output command needs to have a > >header describing what type of MI output command is being transmitted. > >With this knowledge, the front end would understand exactly what > >information it needs to grab from the parse tree. Otherwise, the front > >end gets confusing at best. > > 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. 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. 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. Do any of the GDB MI maintainers see this as possible? Please look at my Email http://sources.redhat.com/ml/gdb/2004-09/msg00173.html Thanks, Bob Rossi