Re: RFC: MI output during program execution

[Jim Ingham <jingham at apple dot com>]

Bob,

On Aug 12, 2005, at 5:22 PM, Bob Rossi wrote:

> > > 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.
> >
> > This should work fine.  Actually, the "events" that Keith introduced
> > seems easier to do, since it looks like there's already an event call
> > wherever there is a "deprecated_*_hook" but I am not sure what the
> > difference between events & observers is supposed to be...
>
> OK, unfortunatly, I'm still trying to catch up here. I think I
> understand the observer approach, however, what is the event approach?
> Is that different than the "hooks" you have?

I don't have a good answer here, there is some history that I don't  
fully understand.  There used to be _hook functions, that you put in  
various interesting places in gdb, and called like:

  if (create_breakpoint_hook)
    create_breakpoint_hook (b);

So in the MI, when I am about to call into the cli interpreter, first  
I put in place a bunch of hooks, and then they get called to tell me  
if anything interesting happens.

In current TOT gdb, I see instead:

  if (deprecated_create_breakpoint_hook)
    deprecated_create_breakpoint_hook (b);
  breakpoint_create_event (b->number);

where breakpoint_create_event does:

void
breakpoint_create_event (int b)
{
  if (gdb_events_debug)
    fprintf_unfiltered (gdb_stdlog, "breakpoint_create_event\n");
  if (!current_event_hooks->breakpoint_create)
    return;
  current_event_hooks->breakpoint_create (b);
}

Okay...

So it LOOKS like the "events" are supposed to be the replacements for  
the hooks...

But then there's the whole observer thing, which from what I read of  
the gdb-patches traffic at the time was supposed to be a more general  
solution for watching interesting events.  But it doesn't seem to be  
used all that much.

So I am not really sure what's supposed to be happening here.

Moving from hooks to events seems a trivial formal exercise.  I don't  
know if they will get deprecated soon or what, however...

> > > Anyone else willing to work towards this solution?
> > >
> > > 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"]
> > >
> > > I might even prefer,
> > >   =breakpoint-changed,thread-changed
> > > which would then allow the FE to call -list-breakpoints or  
> > > whatever if
> > > they are interested.
> >
> > Why?  These sorts of events are never going to have that much data in
> > them.  Why would you want to force another round trip just to avoid
> > packaging up some data that you already have on hand.  That just
> > makes the UI's job more complicated.  For instance, if a breakpoint
> > command set a breakpoint and started the target going again,
> > currently you are going to have to stop the target to get the
> > breakpoint list, which seems silly.  And even if we made "-break-
> > info" a command that you can issue while the target is going, what if
> > it stopped again between you sending the break info and it getting
> > processed.  You will get another async message before you get the
> > break info response...
> >
> > Of course the UI has got to be robust against this sort of thing, but
> > I see no reason to make the job arbitrarily complex.
> >
> > Again, what is your reason for wanting to do this?
>
> Well, I just figured it would be easier to say, "This has changed",
> instead of giving the entire change. However, if I'm wrong here,  
> that is
> fine. It's easy to change this kind of thing once the functionality is
> in place. As long as the approach is aggreed on, then I think we'll  
> all
> be happy.

Cool...

Jim