Re: asynchronous MI output commands

[Jim Ingham <jingham at apple dot com>]

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.

Jim



On May 11, 2006, at 8:02 AM, Bob Rossi wrote:

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