From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6266 invoked by alias); 11 May 2006 19:31:21 -0000 Received: (qmail 6257 invoked by uid 22791); 11 May 2006 19:31:20 -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 19:31:13 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 May 2006 15:31:11 -0400 Message-ID: <3518719F06577C4F85DA618E3C37AB910535A0CE@nimbus.ott.qnx.com> From: Alain Magloire To: Daniel Jacobowitz , gdb@sources.redhat.com Subject: RE: asynchronous MI output commands Date: Fri, 12 May 2006 00:19: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/msg00154.txt.bz2 > From: Daniel Jacobowitz [mailto:drow@false.org] > > On Thu, May 11, 2006 at 08:42:03AM -0700, Jim Ingham wrote: > > I think that the lack of notification about what has gone on when > > somebody uses interpreter-exec to run the target is just a bug in the > > interpreter-exec command. Since that command allows lots of stuff to > > go on behind the MI client's back, you need to inform the client > > about this. You could either post asynchronous notifications about > > what happened (for instance an =running or whatever) or you can just > > make the -interpreter-exec command behave like -exec-next when it > > does indeed run the target. The latter is what we did for Xcode, so > > you get the *stopped message if the target was run. > > This is a topic I'd like to see a single consensus on, sometime soon. > I have an ulterior motive. > > I wrote, some time ago, patches to use Guile to implement GDB CLI > commands. It works by, roughly, opening a bidirectional MI channel to > Guile, and temporarily suspending the CLI channel. But if the front > end in use is MI, what notifications should that frontend get? Should > it be told the target is running, even if e.g. the user defined command > just calls a function in the target? Should the Guile interpreter get > notifications when the user or MI client does something? > IMHO, the MI interpreter should get a notification when the target changes state from a side effect of CLI commands. So the example, when the "runs" command is executed (next, step, call, finish, signal etc...) an OOB should be drop: ^running Or for example if an external application drops a SIGINT on the inferior, I do expect a notification. *stopped,... The GDB CLI channel probably does not need notification because the protocol was not meant for this but rather a direct access by the users to gdb commands, strictly query/answers. > Basically, I think that getting this right requires multiple > interpreters live at the same time. > Is there really a case for this? The scenario I see is within one interpreter (say MI), you want to give more power to the users and let them access advanced gdb commands, so the interpreter-exec provides this nicely. The only problems is the side effects. Notification does not have to be complex, for example something like: =state_change Notification, could tell the front end to reload the settings (the breakpoints, the watchpoints, dlls, etc ...) > I'd like to come back to that code someday. And, preferably, merge > Perl and Python support also. Kip Macy posted Perl bindings and the > Python ones would be easy to write, now that I know Python - in fact > it's the only one out of the three I'd be comfortable doing myself, > the Guile bits were very skeletal. >