Re: RFC: MI output during program execution

Jim Ingham
2005-08-13T00:33:17Z

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