From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22964 invoked by alias); 8 May 2006 01:26:20 -0000 Received: (qmail 22956 invoked by uid 22791); 8 May 2006 01:26:19 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 08 May 2006 01:26:17 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FcuVr-0005x9-RC for gdb@sourceware.org; Sun, 07 May 2006 21:26:15 -0400 Date: Mon, 08 May 2006 02:03:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: asynchronous MI output commands Message-ID: <20060508012615.GA22814@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20060506040637.GA14894@nevyn.them.org> <20060506114933.GF25114@brasko.net> <20060506152046.GA24267@nevyn.them.org> <20060506164030.GK25114@brasko.net> <20060506165249.GA25972@nevyn.them.org> <20060506194618.GL25114@brasko.net> <20060506203741.GA29439@nevyn.them.org> <20060507004518.GM25114@brasko.net> <20060507212711.GA18344@nevyn.them.org> <20060508002935.GN25114@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060508002935.GN25114@brasko.net> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00075.txt.bz2 On Sun, May 07, 2006 at 08:29:35PM -0400, Bob Rossi wrote: > OK. I start with the MI output. I use bison to convert that into an > abstract parse tree. Now, I am working on a solution to take the > abstract parse tree and turn it into a simple to use representation for > the front end (ADT). I gave the example earlier, taking the abstract parse > tree for -file-list-exec-source-file > ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c" > and turn that into > struct file_list_exec_source_file > { > int line; > char *file; > char *fullname; > }; > struct file_list_exec_source_file result = { 26, "test.c", "/home..."}; [What's ADT mean then? The "A" can't be abstract, there's nothing abstract about this.] > > You don't > > need to know what the data is to do that. If you want to create > > individual response structure types for each supported MI command, then > > you ought to know what command is being answered (see my mail a moment > > ago for why), and be able to convert the _abstract_ tree into an > > appropriate _concrete_ structure. > > Yes, I agree, if I knew the MI input command, I could use that to > determine what type of command I was looking at. If I won't be allowed > to add the command to the output record, then this is what I will do. > > However, I would like to be able to do this with out knowing the MI input > command. First, it makes the code more modular that takes the MI output > and turns it into something meaningful. Second, it's easy to gather a > bunch of MI output commands from the test suite or from FE user's with > FE problem, and parse just that output. Third, it validates that what > the user requested is what the user is getting. It is possible that the > FE and GDB could get mixed up I'm assumming. You're trying to turn a response into a meaningful message without knowing what it's a response to. I just don't see the benefit of this; although people keep telling me it's harder than I understand, I still haven't seen an example that I consider plausible. It's easy to gather output from e.g. the testsuite, true. But it's equally easy to record the commands - just about everything is going to go through mi_gdb_test, or you could even write a proxy between the testsuite and GDB which logged, or add the logging to GDB directly. I know Eclipse's MI protocol log includes the commands it sent. Your third point is valid, but does not seem particularly important to me. If it's wrong, it's wrong. GDB would just have to stitch the command name on at the end right before outputing the result record, so that wouldn't gain you much at all. > Anyways, Daniel, thanks for taking time out of your busy schedule to > think about this issue. If you simply don't want something like this in > MI right now, I'll find a way to match the input with the output. I'm not supreme dictator of this stuff; someone else is welcome to step in and disagree. I'm just not convinced, either. -- Daniel Jacobowitz CodeSourcery