Re: MI non-stop mode spec

[Pawel Piech <pawel dot piech at windriver dot com>]

Hi Nick,
Thank you for the reply.  I'm still rather curious what you, Vladimir, 
and anyone else think of the rest of my suggestions. 

Nick Roberts wrote:
>  > I don't fully understand why disabling CLI commands is desired, but I'm 
>  > guessing it's because the CLI commands would still rely on the current 
>  > thread.  If so, then keeping the MI protocol stateful would hopefully 
>  > address that concern and not force you to disable the CLI interface, 
>  > which would be unfortunate.
>
> It's probably not desired but it's certainly more effort.  Perhaps the customer
> in question can be persuaded of it's value: it's certainly important for any
> frontend that wants to keep the console.  This still provides access to a lot
> of funtionality in GDB that hasn't yet been properly implemented in MI.
>   
I think it would be a great disservice to GDB to disable the console.  
Even though the console in the IDE is pretty broken for the reasons you 
mention, a lot of our Eclipse users still value it greatly, so fixing 
it's interaction with MI would actually be very good for GDB.
> Currently commands like -break-insert gives synchronous MI output for the
> frontend to parse while the CLI command "break" issued under MI,
> "-interpreter-exec console break", say, just gives CLI output.  I think this is
> the wrong approach and that -break-insert shouldn't generate the output
> directly but instead MI should generate event notifications informing the
> frontend of changes:
>
> =breakpoints-changed,...
>
> This could be done with observers like Vladimir has done for threads and
> would produce the same notifications regardless of whether the breakpoint
> was created with a CLI or MI command.
>
> Likewise with the new commands for non-stop mode
Thank you for the explanation.  I agree.  Currently MI lacks out of band 
notifications for thread state changes (it has a running event only), 
thread lifecycle events, memory changed events, registers changed 
events, modules changed events, and as you mention above breakpoints 
changed events.  Like I said, I'm not familiar with GDB internals, but 
since CLI has notifications for most of these I can't imagine it would 
be that hard to add them to MI.

One note about the =breakpoints-changed proposed above.  I think it 
would be a mistake to just replace the ^done reply to 
-break-insert/-break-remove with an event alone, because a client would 
have no way of knowing whether an event was in response to that client's 
request or another client's request.  I.e. a client would not be able to 
positively determine the ID of the breakpoint he just created.  I see 
two equally good ways to address this:
1) Add the =breakpoints-changed event in addition to the ^done with 
breakpoint info, but the =breakpoints-changed would have to be sent 
AFTER the ^done reply.
2) Allow clients to specify their own arbitrary ID for a breakpoint, 
with an option such as -client-id="abc".  Then have the 
=breakpoints-changed event and other query commands echo the client-id 
along with the regular breakpoint ID.

Cheers,
Pawel