From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31257 invoked by alias); 11 May 2006 10:40:00 -0000 Received: (qmail 31249 invoked by uid 22791); 11 May 2006 10:39:59 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao02.cox.net (HELO eastrmmtao02.cox.net) (68.230.240.37) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 10:39:56 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao02.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060511103954.WOLJ15470.eastrmmtao02.cox.net@localhost.localdomain>; Thu, 11 May 2006 06:39:54 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1Fe8aw-0007tU-DP; Thu, 11 May 2006 06:40:34 -0400 Date: Thu, 11 May 2006 10:48:00 -0000 From: Bob Rossi To: Vladimir Prus Cc: Alain Magloire , gdb@sources.redhat.com Subject: Re: asynchronous MI output commands Message-ID: <20060511104034.GE3727@brasko.net> Mail-Followup-To: Vladimir Prus , Alain Magloire , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB9105359CCA@nimbus.ott.qnx.com> <20060511023711.GB3727@brasko.net> <200605111008.15930.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605111008.15930.ghost@cs.msu.su> 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/msg00128.txt.bz2 On Thu, May 11, 2006 at 10:08:15AM +0400, Vladimir Prus wrote: > On Thursday 11 May 2006 06:37, Bob Rossi wrote: > > > > > It's hard to believe that response from MI can be useful without > > > > knowing the > > > > last issued command. Say, response from -data-evaluate-expression is > > > > useless if you don't know what part of frontend wants that data -- > > > > evaluating expression is used in many use cases. So, you need to > > > > associate extra data with commands anyway. > > > > > > I agree, the example that comes to my mind is "next", "step", "finish", > > > "continue" etc ... To do some optimization front-ends will probably need > > > to know the last command issue (for example clearing all the variable > > > state in a variable view for "continue"). > > > > I see the point, however, how do you know if the user typed continue? I > > allow the user to have access to the console, and by doing so, I can't > > make any assumptions on what GDB is doing. > > The "continue" command always produces > > *stopped > > response and that's mostly enough for frontend. OK, this isn't true. I used GDB CVS for this. (gdb) -break-insert main.c:4 ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x08048364",func="main",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="4",times="0"} (gdb) -break-insert main.c:5 ^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0804836b",func="main",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="5",times="0"} (gdb) -exec-run ^running (gdb) *stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x08048364",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffbc9a4"}],file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c",line="4"} (gdb) -interpreter-exec console "continue" ~"Continuing.\n" ~"\n" ~"Breakpoint 2, main (argc=1, argv=0xbffbc9a4) at main.c:5\n" ~"5\t argc = 2;\n" ^done (gdb) The continue command doesn't give a *stopped. > > > Maybe I'm mistaken but I have the impression, looking at the thread, some > > > folks are confusing OOB and synchronous response that comes after issuing > > > a command. > > > > I'm hopefull not confusing them, but maybe. For synchronous commands, I > > just think it's a little ugly that you need the MI input command to > > determine what an MI output command is. > > What do you mean by "determine what an MI output command is"? You certainly > can parse the response into DOM-like tree without knowing the output command. > If you want to create C data structures for each response, then yes, you'd > need to know the exact type of the last command. But then, I'm not sure why > you want to use C data structures. In KDevelop, the DOM is fully dynamic and > that works just fine, for example: > > const GDBMI::Value& children = r["children"]; > > for (unsigned i = 0; i < children.size(); ++i) > { > QString exp = children[i]["exp"].literal(); > > > If you have specific structures for each response this won't be very much > simpler. Sorry, I've described this before, but apparently not good enough. I definatly can create the abstract parse tree with out knowing the input command. However, then I want to create C data structures for each MI output. I need the MI input command to do that. I was hoping an extension to the MI output would be allowed to get around this. > > For asynchronous commands, there is simply no way to know what you are > > looking at AFAIK. > > What exactly do you want to know that's not obtained from parse tree? I need slightly more information and to do a little more testing to describe the problem above in certanty. When I get to that point I'll start another thread that's more meaningful. Bob Rossi