RFC: MI output during program execution

[Jim Ingham]

On Aug 11, 2005, at 6:28 PM, 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.

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...

>
> 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?

Jim


>
> 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).
>
> Thanks,
> Bob Rossi
>