From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15512 invoked by alias); 6 May 2006 01:26:40 -0000 Received: (qmail 15499 invoked by uid 22791); 6 May 2006 01:26:39 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao06.cox.net (HELO eastrmmtao06.cox.net) (68.230.240.33) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 May 2006 01:26:37 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao06.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060506012635.GFTA16402.eastrmmtao06.cox.net@localhost.localdomain> for ; Fri, 5 May 2006 21:26:35 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FcBZa-0007o2-RP for gdb@sources.redhat.com; Fri, 05 May 2006 21:27:06 -0400 Date: Sat, 06 May 2006 01:26:00 -0000 From: Bob Rossi To: gdb@sources.redhat.com Subject: asynchronous MI output commands Message-ID: <20060506012706.GA25114@brasko.net> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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/msg00040.txt.bz2 Hi, I'm finally getting more time to build the next layer on top of my MI parser. This layer will look at the parse tree and create a data structure from it that the front end will find more useful. For instance, for example, 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. 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. The first problem that I've run into is determining if an MI output command is synchronous or asynchronous. I can tell if the MI output command is asynchronous by looking for, reason="abc", like below, 47*stopped,reason="end-stepping-range",thread-id="0", ... I'm assuming reason= has to be the first pair after stopped, or done,. 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", ... Thanks, Bob Rossi