From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7480 invoked by alias); 6 May 2006 03:27:52 -0000 Received: (qmail 7472 invoked by uid 22791); 6 May 2006 03:27:51 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 May 2006 03:27:49 +0000 Received: from farnswood.snap.net.nz (p202-124-114-183.snap.net.nz [202.124.114.183]) by viper.snap.net.nz (Postfix) with ESMTP id 6216D754D31; Sat, 6 May 2006 15:27:47 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id CB457627ED; Sat, 6 May 2006 04:27:05 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17500.6025.227765.592238@farnswood.snap.net.nz> Date: Sat, 06 May 2006 03:27:00 -0000 To: Bob Rossi Cc: gdb@sources.redhat.com Subject: asynchronous MI output commands In-Reply-To: <20060506012706.GA25114@brasko.net> References: <20060506012706.GA25114@brasko.net> X-Mailer: VM 7.19 under Emacs 22.0.50.45 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/msg00044.txt.bz2 > 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. > 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? > 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. -- Nick http://www.inet.net.nz/~nickrob