Re: RFC: MI output during program execution

Daniel Jacobowitz
2005-08-12T21:01:57Z

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