Re: RFC: MI output during program execution

[Daniel Jacobowitz <drow@false.org>]

On Thu, Aug 11, 2005 at 09:28:10PM -0400, Bob Rossi wrote:
> > Remember I haven't done this with observers or events yet.  The way I  
> > did it with hooks, the result of the hooks is gathered into the  
> > "^done" or the other termination states for the command.  So for  
> > instance, if you run gdb on itself, and do:
> 
> Hi Jim,
> 
> Thanks for all the guidence so far. Even though you have not attempted
> the observer approach, how do you feel about it? Is this something that
> you think could be accomplished with the current FSF GDB? Nick, Daniel
> and Eli, do you like this approach? I'm sure I could find some time to 
> get something going in this direction, with a little bit of thought.

Just to clarify what I said downthread to Eli: I don't think that this
requires "observers" in any sense.  I think we want to do something
specific to notifying interpreters, or even something specific to
notifying the MI interpreter (I'm not sure which is a better idea, to
be honest).  So perhaps you should find something else to call it :-)

> I really like Daniel's idea of just alerting the user that something has
> changed, instead of actually giving the user the data. For instance he
> had,
> 
>    =breakpoint-changed,[bpnum="1",state="disabled"]
>    =thread-changed,[thread="2"]

That wasn't my idea, although they were my examples - those were
exactly the available information.  I support providing the data,
unless it becomes large or complicated.  Which it may especially for
breakpoints!  We need an implementation to experiment with.

> This is very similar to how annotate=2 solved the problem for when
> breakpoints changed. The only wierd issue that happened with this
> approach is that the data breakpoint-changed was literally outputted
> thousands and thousands of times in certain circumstances. (compiled
> program with optimizations).

Fortunately, this is pretty easy to handle in MI land.  I suspect that
we will usually only want the notification once if it's just
=breakpoint-changed.  Especially if we can manage the interface so that
user events generate notifications but program events don't need to...

The example that concerns me is loading a shared library and having it
shuffle many breakpoints around.

-- 
Daniel Jacobowitz
CodeSourcery, LLC