This is the mail archive of the
mailing list for the GDB project.
Re: MI return error changed from 6.3 to 6.4?
> > Manual> This mechanism is provided as an aid to developers of GDB/MI
> > Manual> clients and not as a reliable interface into the CLI. Since the
> > Manual> command is being interpreteted in an environment that assumes
> > Manual> GDB/MI behaviour, the exact output of such commands is likely to
> > Manual> end up being an un-supported hybrid of GDB/MI and CLI output.
> > so maybe we shouldn't fix it.
> Alternatively, we could leave what manual says as it is now, and fix
> the code. Note that it says that _existing_ CLI commands are
> accepted. So perhaps we should detect non-existing commands and
> return an MI error indication.
I seem to also recall that Andrew also said that using CLI through MI was a
temporary arrangement (although I can't find that in the manual).
> > On the other hand this was written before the command -interpreter-exec.
> > If entering CLI commands directly (using -interpreter-exec implicitly)
> > can be made as reliable as using -interpreter-exec explicitly, maybe this
> > would be a convenient alternative, and the above paragraph could be
> > removed from the manual.
> Such an incompatible change would require a quarantine period during
> which the CLI support in MI is marked deprecated.
What's incompatible? I mean in addition to, not instead of and here I'm
suggesting the opposite i.e that CLI support in MI is not deprecated. My
feeling is that -interpreter-exec *does* provide a reliable interface into the
CLI while the hack that was used in GDB 6.3 didn't. I'm just saying that we
may as well use it access CLI directly from MI. First though I think we
should formally document the syntax of MI and CLI commands so that they don't
get confused. CLI commands seem to always start with a lower case letter
while MI commands start with "-" (I see TUI uses "-" to mean scroll backward).