This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop mode spec
> 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