From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29850 invoked by alias); 6 May 2006 12:06:29 -0000 Received: (qmail 29842 invoked by uid 22791); 6 May 2006 12:06:28 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao04.cox.net (HELO eastrmmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 May 2006 12:06:26 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao04.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060506120624.FKXJ9931.eastrmmtao04.cox.net@localhost.localdomain>; Sat, 6 May 2006 08:06:24 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FcLYm-00063I-E6; Sat, 06 May 2006 08:06:56 -0400 Date: Sat, 06 May 2006 16:40:00 -0000 From: Bob Rossi To: Nick Roberts Cc: gdb@sources.redhat.com Subject: Re: asynchronous MI output commands Message-ID: <20060506120656.GJ25114@brasko.net> Mail-Followup-To: Nick Roberts , gdb@sources.redhat.com References: <20060506012706.GA25114@brasko.net> <17500.6025.227765.592238@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17500.6025.227765.592238@farnswood.snap.net.nz> User-Agent: Mutt/1.5.9i 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/msg00055.txt.bz2 On Sat, May 06, 2006 at 03:27:05PM +1200, Nick Roberts wrote: > > Starting with this MI output command, > > -file-list-exec-source-file > > ^done,line="1",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c" > > (gdb) > > I get back a parse tree, and from that, I'll define something like, > > > > struct file_list_exec_source_file > > { > > int line; > > char *filename; > > char *fullname; > > }; > > > > with the correct values filled in. > > Presumably Emacs would need the parser to output Lisp. Sounds great to me. > > So far, I've created the parse tree code, and a small TCL extension > > which allows me to grab all of the MI output commands from the > > testsuite. I've written all of these output commands to a temporary file, > > which I use for input to my drive program. > > Emacs has a Lisp interpreter, of course, so it could take Lisp output from a > parser and act on it. AFAIK C isn't interpreted, so how does your program use > it? I probably wasn't clear here. I have the MI parser, which just creates the parse tree. I wrote a small TCL extension that is capable of taking an MI output command and writing it to a file if the parse passed. set parse_result [gdbmi_parse $expect_out(2,string)] if [string match "syntax error" $parse_result] then { puts "MI_OUTPUT_COMMAND($expect_out(2,string))" fail "Syntax check of MI Output Command failed" } else { puts -nonewline $fileId $expect_out(2,string) } So, after I run the testsuite, I have all the valid MI output commands from the test suite in /tmp/data.mi. Then, I have a driver program which reads a file that has MI descriptions in it (/tmp/data.mi) and parses each of them. I am know starting to work on the part that takes the parse tree and provides a semantically correct data structure for the front end to use. The only reason I wrote the tcl extension is to validate the test suite. It turned out I was also easily able to gather a bunch of MI output commands for testing as well. > > My question is, should we say it's a bug on GDB's part if reason= isn't > > the first pair returned for an asynchronous MI output command? Should I > > assume if the MI output command has reason= anywhere in it that it's an > > asynchronous command? or should we add an extra piece of information into > > the MI output command stating that the command is asynchronous. > > For instance, > > > > 47*stopped,asynchronous,reason="end-stepping-range",thread-id="0", ... > > I think you should assume that if it has *stopped, the output is asynchronous. > Of course, as we've said before, currently all the output (except possibly for > a remote target) is synchronous in reality. OK, I will take your suggestion, as well as Daniel's on this point. Thanks for the help. Bob Rossi