Re: RFC: MI output during program execution

[Jim Ingham <jingham@apple.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