Re: asynchronous MI output commands

[Jim Ingham <jingham at apple dot com>]

On May 11, 2006, at 9:22 AM, Daniel Jacobowitz wrote:

> 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?

> Basically, I think that getting this right requires multiple
> interpreters live at the same time.

I'm not sure I understand the design.  Does the user have access both  
to the MI channel (presumably through the Guile interface) and to the  
normal gdb CLI interpreter?  That does sound like it would be hard to  
get right...

In our case, we funnel all access to the CLI through the -interpreter- 
exec command.  So we do need to be careful that the -interpreter-exec  
wrapper arranges to tell the MI about all the things that the CLI  
command might do (including setting breakpoints, changing the frame,  
running the target, etc).  But I don't think the Xcode design  
requires two interpreters live simultaneously, it just requires that  
the notification hooks be sufficient for the purposes.

BTW, we don't notify the UI that the target has run if you just call  
a function.  Maybe we should so the UI could better figure out what  
is going on if a user called function stalls for some reason, but it  
makes the UI's life simpler if it doesn't know about this.

Jim

> 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.
>
> --
> Daniel Jacobowitz
> CodeSourcery