Re: MI non-stop mode spec

[Nick Roberts <nickrob@snap.net.nz>]

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

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.

-- 
Nick                                           http://www.inet.net.nz/~nickrob