From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1676 invoked by alias); 11 May 2006 14:59:23 -0000 Received: (qmail 1387 invoked by uid 22791); 11 May 2006 14:59:19 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 14:58:11 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 May 2006 10:58:08 -0400 Message-ID: <3518719F06577C4F85DA618E3C37AB9105359F5C@nimbus.ott.qnx.com> From: Alain Magloire To: gdb@sources.redhat.com Subject: RE: asynchronous MI output commands Date: Thu, 11 May 2006 15:02:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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/msg00143.txt.bz2 > > > 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 > > 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? 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... > Bob Rossi