From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6010 invoked by alias); 11 May 2006 15:02:18 -0000 Received: (qmail 6000 invoked by uid 22791); 11 May 2006 15:02:17 -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; Thu, 11 May 2006 15:02:12 +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 <20060511150210.QTRZ16402.eastrmmtao06.cox.net@localhost.localdomain>; Thu, 11 May 2006 11:02:10 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FeCgj-0001Wv-LN; Thu, 11 May 2006 11:02:49 -0400 Date: Thu, 11 May 2006 15:42:00 -0000 From: Bob Rossi To: Alain Magloire Cc: gdb@sources.redhat.com Subject: Re: asynchronous MI output commands Message-ID: <20060511150249.GA1600@brasko.net> Mail-Followup-To: Alain Magloire , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB9105359F5C@nimbus.ott.qnx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3518719F06577C4F85DA618E3C37AB9105359F5C@nimbus.ott.qnx.com> 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/msg00145.txt.bz2 On Thu, May 11, 2006 at 10:58:08AM -0400, Alain Magloire wrote: > > > > > > For the record, that's basically what I have in KDevelop. There's > > command > > > > queue, and commands are sent to gdb one-at-a-time, and responses come > > > > exactly in the same order. Remembering the last issued command (i.e. > > > > instance of GDBCommand class internal to KDevelop) makes it possible > > to > > > > route the response back to the original command. > > > > > > > > I'm don't quite understand the problems being discussed in this > > thread. > > > > It's > > > > not apparent why one has to know the type of the last command while > > > > parsing, and if so, why remembering the last command is bad idea. > > > > > > > > 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. > > > > I suppose you could intercept the CLI commands before sending it to GDB This isn't a good idea, and probably impossible. Don't forget about user defined commands. Also, don't forget that hitting a breakpoint can run some commands. You never really know when 'continue' is sent. > > > 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. > > > > You can certainly parse the MI output without knowing what the input was. > The problem is when you get answer what do you do with it? Yes, sorry this is what I mean. Geez, I'm not good at expressing myself. > For example > -data-evaluate-expression may be an action for hovering or to update a tree > viewer etc... Most commands are "synchronous" i.e. an answered to a > question. Usually front ends will have callbacks attach to the MI > question/command. > > > > For asynchronous commands, there is simply no way to know what you are > > looking at AFAIK. You just have to poke around until your fingers get > > tired. I still need to research this more though. > > > > OOB were suppose to be a way for GDB to notify of changes, that did not come > from a user action. Comes to mind hitting a breakpoint, thread creation, > loading of a library, etc... I need to play more with these. Thanks for the suggestions. Bob Rossi