MI return error changed from 6.3 to 6.4?

MI return error changed from 6.3 to 6.4?

[Dirk Behme]

Hello,

after upgrade from GDB 6.3 to 6.4 I noticed that the error 
return behavior of MI interface invoked by 
"--interpreter=mi" changed. While with 6.3 an "^error" was 
returned which can be used by programs to react, 6.4 only 
returns "^done":

GDB 6.3:

(gdb)
ererwrererwrewr
&"ererwrererwrewr\n"
&"Undefined command: \"ererwrererwrewr\".  Try \"help\".\n"
^error,msg="Undefined command: \"ererwrererwrewr\".  Try 
\"help\"."
(gdb)

GDB 6.4:

(gdb)
srwwerrweweer
&"srwwerrweweer\n"
&"Undefined command: \"srwwerrweweer\".  Try \"help\".\n"
^done
(gdb)

With this, a GUI interface has the problem that it can't 
decide if the GDB
has some problems parsing the command given to it or not 
because it scans for
the "^error" string as result. With 6.4 this doesn't work 
any more.

Do I miss anything here? What is the new recommended way to 
do this job?

Sorry if this is a FAQ, but searching release note and list 
archives I can't find a hint for this.

Thanks

Dirk

Re: MI return error changed from 6.3 to 6.4?

[Daniel Jacobowitz]

On Fri, Apr 07, 2006 at 05:54:57PM +0200, Dirk Behme wrote:
> GDB 6.4:
> 
> (gdb)
> srwwerrweweer
> &"srwwerrweweer\n"
> &"Undefined command: \"srwwerrweweer\".  Try \"help\".\n"
> ^done
> (gdb)

Two things.  Here's the cause:

1108            argv[0] = "console";
1109            argv[1] = context->command;
1110            mi_cmd_interpreter_exec ("-interpreter-exec", argv, 2);
1111
1112            /* If we changed interpreters, DON'T print out anything. */
1113            if (current_interp_named_p (INTERP_MI)
1114                || current_interp_named_p (INTERP_MI1)
1115                || current_interp_named_p (INTERP_MI2)
1116                || current_interp_named_p (INTERP_MI3))
1117              {
(gdb) 
1118                /* print the result */
1119                /* FIXME: Check for errors here. */
1120                fputs_unfiltered (context->token, raw_stdout);
1121                fputs_unfiltered ("^done", raw_stdout);
1122                mi_out_put (uiout, raw_stdout);
1123                mi_out_rewind (uiout);
1124                fputs_unfiltered ("\n", raw_stdout);
1125                args->action = EXECUTE_COMMAND_DISPLAY_PROMPT;
1126                args->rc = MI_CMD_DONE;
1127              }

mi_cmd_interpreter_exec has conveniently returned MI_CMD_ERROR.
So, this should be easy to fix.  Thanks for the report.

> With this, a GUI interface has the problem that it can't decide if
> the GDB has some problems parsing the command given to it or not
> because it scans for the "^error" string as result. With 6.4 this
> doesn't work any more.

This only happens if you're sending CLI commands (i.e. commands which
don't start with a "-") to GDB directly.  Otherwise you'll get the
expected ^error.  A better way to do this than relying on "the CLI
hack" for unknown commands is to use the new -interpreter-exec, and
that will return the error OK:

zz
&"zz\n"
&"Undefined command: \"zz\".  Try \"help\".\n"
^done
(gdb) 

-interpreter-exec console "zz"
&"Undefined command: \"zz\".  Try \"help\".\n"
^error,msg="Undefined command: \"zz\".  Try \"help\"."
(gdb) 

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI return error changed from 6.3 to 6.4?

[Nick Roberts]

 > mi_cmd_interpreter_exec has conveniently returned MI_CMD_ERROR.
 > So, this should be easy to fix.  Thanks for the report.

However the manual says:

Manual>    To help users familiar with GDB's existing CLI interface, GDB/MI
Manual> accepts existing CLI commands.  As specified by the syntax, such
Manual> commands can be directly entered into the GDB/MI interface and GDB will
Manual> respond.

Manual>    This mechanism is provided as an aid to developers of GDB/MI clients
Manual> and not as a reliable interface into the CLI.  Since the command is
Manual> being interpreteted in an environment that assumes GDB/MI behaviour,
Manual> the exact output of such commands is likely to end up being an
Manual> un-supported hybrid of GDB/MI and CLI output.

so maybe we shouldn't fix it.

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.


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

Re: MI return error changed from 6.3 to 6.4?

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 8 Apr 2006 09:53:12 +1200
> Cc: Dirk Behme <dirk.behme@googlemail.com>, gdb@sourceware.org
> 
> However the manual says:
> 
> Manual>    To help users familiar with GDB's existing CLI interface, GDB/MI
> Manual> accepts existing CLI commands.  As specified by the syntax, such
> Manual> commands can be directly entered into the GDB/MI interface and GDB will
> Manual> respond.
> 
> Manual>    This mechanism is provided as an aid to developers of GDB/MI clients
> Manual> and not as a reliable interface into the CLI.  Since the command is
> Manual> being interpreteted in an environment that assumes GDB/MI behaviour,
> Manual> the exact output of such commands is likely to end up being an
> Manual> 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.

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

Re: MI return error changed from 6.3 to 6.4?

[Nick Roberts]

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


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

Re: MI return error changed from 6.3 to 6.4?

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 8 Apr 2006 20:22:47 +1200
> Cc: drow@false.org, dirk.behme@googlemail.com, gdb@sourceware.org
> 
>  > > 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.

It sounded like the suggested removal of the paragraph in the manual
means that we are removing the CLI command support in MI.  Sorry if I
misunderstood.

Re: MI return error changed from 6.3 to 6.4?

[Nick Roberts]

 > It sounded like the suggested removal of the paragraph in the manual
 > means that we are removing the CLI command support in MI.  Sorry if I
 > misunderstood.

I see your point.  Yes, if we kept CLI command support in MI it would
probably be sensible to to rewrite the paragraph, not remove it.

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