From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13653 invoked by alias); 7 May 2006 00:44:50 -0000 Received: (qmail 13645 invoked by uid 22791); 7 May 2006 00:44:49 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao03.cox.net (HELO eastrmmtao03.cox.net) (68.230.240.36) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 07 May 2006 00:44:47 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060507004445.JDRX15797.eastrmmtao03.cox.net@localhost.localdomain> for ; Sat, 6 May 2006 20:44:45 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FcXOg-0002wy-FI for gdb@sourceware.org; Sat, 06 May 2006 20:45:18 -0400 Date: Sun, 07 May 2006 20:42:00 -0000 From: Bob Rossi To: gdb@sourceware.org Subject: Re: asynchronous MI output commands Message-ID: <20060507004518.GM25114@brasko.net> References: <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> <20060506194618.GL25114@brasko.net> <20060506203741.GA29439@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060506203741.GA29439@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/msg00061.txt.bz2 > > 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. > > That's not the difference between synchronous and asynchronous, in MI: > think of it instead as the difference between synchronous and > everything else. A synchronous response from MI corresponds to a > front-end command. Everything else corresponds to other state changes, > which may be related to some command or not, in a less than obvious > way. OK, with that information, I see it is impossible to tell just from looking at the MI output, to determine if the command is synchronous or not. Look below for a solution to this problem for me. > You can easily categorize a ^done or ^error response as synchronous. > Other responses are more difficult to associate with a command, because > they weren't directly issued as the response to a command. > > > 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) > > Accomplishing what? This is synchronous. It's a response to the > previously issued command. The front end knows exactly what its > previously issued command was, I hope. Hmmm. That's interesting, I was hoping to not need to know what the input command was in order to parse and build an ADT for the output. In general, I think it would be appropriate if the MI output described itself well enough that no other information was needed to understand it, including the MI intput command. I think I could accomplish this task, as well as understand what is synchronous and asynchronous by adding a little bit of output to each synchronous command like shown above. Showing the MI command that GDB is responding to in the MI output would do just the trick. Would a simple patch that changed the output like this be welcome? from result-record ==> [ token ] "^" result-class ( "," result )* nl to something like result-record ==> [ token ] mi-input-command "^" result-class ( "," result )* nl The above is just a simple suggestion to show the goal. I'm not sure if that would be the best place to change the code. I'd like to do it in a way that didn't break the MI output syntax. Thanks, Bob Rossi