Re: RFC: MI output during program execution

[Jim Ingham <jingham@apple.com>]

On Aug 9, 2005, at 11:23 AM, Bob Rossi wrote:

> On Tue, Aug 09, 2005 at 10:59:25AM -0700, Jim Ingham wrote:
>
>> The front end needs to know if a CLI command executed via "-
>> interpreter-exec console" changed the current thread or frame - so it
>> can update the UI accordingly.  Or if it started the target running.
>> Or if it added a breakpoint.
>>
>> All these things could be queried from existing commands in the MI,
>> but that's pretty inconvenient and inefficient.  It's much easier to
>> code up the UI if gdb tells it asynchronously about these things.
>>
>
> OK, well then I completly agree that observers would be a very nice  
> way
> to solve this problem. When an internal MI state changes, it should
> alert the FE if the FE requested such knowledge. This is of course, an
> asyncronous approach as far as the FE is concerned. If the FE needs  
> this
> information now, it can simply poll GDB for this information.
>
> Also, I'm not convinced it would be inefficient to query GDB for the
> required information, especially if a new MI command was added to GDB
> that returned the current state of GDB. (frame,thread,file).

"Run over all state and see what changed" is a pain compared to "tell  
me when something changes".  If the former were hard to code up for  
some reason, I guess you could go for the latter, but it didn't take  
all that much thought to get this working...

>
> How does -interpreter-exec console work in the case when the user
> executes a command, that makes up several other commands?
>
> define mess_with_mi_people
>    b main
>    r
>    n
>    n
> end
>
> I don't think this case would currently work as expected. Would it?

Remember that only one "run the target" command is allowed in a CLI  
define.  All the others are ignored.

But anyway, in our setup, the UI would get notification that a  
breakpoint was set, and then that the target continued.

A harder one to handle is:

define really_mess_with_people
      break function_that_gets_hit_alot
      commands $bpnum
          print someInterestingVariable
          continue
      end
      r
end

because then you are going to get the breakpoint notification, then  
the run notification, then the breakpoint hit, at which point the  
target is going to start again, etc...  I don't see how you really  
solve this one with the UI polling for state.  But with the hooks and  
just a little bit of judicious trickery (we added a "breakpoint  
commands running" and "breakpoint commands done running" events so  
the UI would know to hold off doing it's "breakpoint hit handling"  
till the commands were done) we have this one working as well.

Jim

>
> Thanks,
> Bob Rossi
>