From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32399 invoked by alias); 6 May 2006 19:45:52 -0000 Received: (qmail 32389 invoked by uid 22791); 6 May 2006 19:45:51 -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 19:45:48 +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 <20060506194546.UMN16402.eastrmmtao06.cox.net@localhost.localdomain> for ; Sat, 6 May 2006 15:45:46 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FcSjK-0000m3-R4 for gdb@sourceware.org; Sat, 06 May 2006 15:46:18 -0400 Date: Sun, 07 May 2006 00:44:00 -0000 From: Bob Rossi To: gdb@sourceware.org Subject: Re: asynchronous MI output commands Message-ID: <20060506194618.GL25114@brasko.net> References: <20060506012706.GA25114@brasko.net> <20060506015903.GA13095@nevyn.them.org> <20060506031435.GE25114@brasko.net> <17500.8198.679332.240864@farnswood.snap.net.nz> <20060506040637.GA14894@nevyn.them.org> <20060506114933.GF25114@brasko.net> <20060506152046.GA24267@nevyn.them.org> <20060506164030.GK25114@brasko.net> <20060506165249.GA25972@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060506165249.GA25972@nevyn.them.org> 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/msg00059.txt.bz2 On Sat, May 06, 2006 at 12:52:49PM -0400, Daniel Jacobowitz wrote: > On Sat, May 06, 2006 at 12:40:31PM -0400, Bob Rossi wrote: > > Each of the lines beggining with ~ are an > > out-of-band-record => stream-record. > > There is no out-of-band-record => async-record. > > > > Certainly having an out-of-band-record => stream-record does not make an > > MI output command asynchronous. Or does it? > > `OUTPUT ==>' > `( OUT-OF-BAND-RECORD )* [ RESULT-RECORD ] "(gdb)" NL' > > It's an OOB record, followed by a prompt. It's not the direct output of > any command. OK, we are going in circles. I currently have a goal of determining if a MI output is synchronous or asynchronous. So far, I think we have agreed that an asynchronous command from GDB is a command that is sent from GDB that was not a response from a command sent to GDB from the FE. GDB uses the term asynchronous all over the place in the manual, even if the asynchronous part is faked. I was under the impression that every asynchronous MI output command would have to funnel through the 'async-record ==>' part of the grammar. You mentioned I could look for *stopped, which is down stream of async-record. So, either this is a special case, or we could put into this case the reason GDB is sending data to the front end, which I think would be appropriate. In fact something like, ~"GNU gdb 6.1-debian\n" ~"Copyright 2004 Free Software Foundation, Inc.\n" ~"GDB is free software, covered by the GNU General Public License, and you are\n" ~"welcome to change it and/or distribute copies of it under certain conditions.\n" ~"Type \"show copying\" to see the conditions.\n" ~"There is absolutely no warranty for GDB. Type \"show warranty\" for details.\n" ~"This GDB was configured as \"i386-linux\"..." ~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n" ~"\n" *stream-update (gdb) and change async-class ==> "stopped" | others (where others will be added depending on the needs--this is still in development). to async-class ==> "stopped" | "stream-update" | others ... I know this seems rather pedantic, and I'm not trying to cause problems where there are none, however, this case just doesn't make sense. Of course I could just consider it synchronous and everything will just work fine, however, I'd like to make this as pure as possible. > > The code I wrote to determine if an MI output command is asynchronous > > checks to see if there is an out-of-band-record=>async-record in the > > parse tree. If there is, the command is asynchronous, otherwise it's > > not. Do you disagree with this? > > "MI output command" doesn't mean anything to me. It's an MI output > record, and it isn't in response to a command. Sorry, I was using the term "MI output command" to mean a single response from GDB to the FE. In the grammar that would be 'output ==>'. > I still don't understand the question - the point of categorizing > messages in this way. I was hoping to tell the front end if the command was asynchronous or not. There is a use in knowing if the command is asynchronous or not. First of, if the command is asynchronous then I don't have to probe the parse tree to determine if it represents the results to say, -file-list-exec-source-file or some other commands. I know when building the ADT for the FE that it's an asynchronous command, and that limits the amount of probing in the parse tree I have to do. Ideally, I wouldn't have to prove at all, GDB should probably state in the MI output what kind of command it's responding to. For instance, instead of -file-list-exec-source-file ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c" (gdb) It could output -file-list-exec-source-file %-file-list-exec-source-file ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c" (gdb) Anyways, I'm going over board for now, but I hope you can see the reason I'm asking for this functionality in the initial response from GDB. Thanks, Bob Rossi