Re: cleanup mi error message handling

Pedro Alves
2008-04-01T00:18:50Z

A Monday 31 March 2008 01:45:18, Nick Roberts wrote:
> > The only thing from you I can find is:
> >
> > At other times duplicated error messages are desirable, e.g.,
> >
> > -exec-continue
> > ^running
> > (gdb)
> > &"The program is not being run.\n"
> > ^error,msg="The program is not being run."
> >
> > because the first goes to the console for the user to see, the second
> > to the frontend to be handled as appropriate.
> >
> > You still did not say why showing the error message is console is
> > desirable. If -exec-continue itself is now show in the console, the
> > error message makes no sense. If -exec-continue is shown, then the error
> > message is not necessary. Where the flaw in this logic.
>
> I can't understand these sentences. The command -exec-continue won't
> appear in the console but "The program is not being run." will. These
> `errors' and other similar ones like "No stack." are reported through error
> () and are normal Gdb output for the user to see. Currently the console
> can display such messages by reading LOG-STREAM-OUTPUT.
>
> Other errors like:
>
> (gdb)
> -interpreter-exec
> ^error,msg="mi_cmd_interpreter_exec: Usage: -interpreter-exec interp
> command" (gdb)
>
> would be due to a frontend error, so I think it would be probably be best
> to display them elsewhare, e.g., status bar.
>

I think the screen should flash and beep three times, and an email
should be automatically sent the the frontend author :-) Seriously,
the status bar doesn't feel right for this. This is not status. This
is GDB complaining to the frontend -- which means the frontend is broken
and isn't doing what the user wants to. A message box with a
"submit bug report" button is in order. If the frontend wants to
probe for gdb version by trying parameters to a command, then, if
all output goes to ^error, and the frontend uses tokens, it is
easy to selectively not display those errors.

> The only way for the frontend to distinguish between the two types of error
> is if the Gdb developer uses the appropriate mechanism, i.e. error () or
> mi_error_message in each case.
>

Then the proper way would be to either add a new ^mi-error, or add
an error class to the output of error, like ^error,class="critical".
Although, I don't advocate the a for this.

> I wouldn't make any changes until a real problem is reported (not just
> Pedro tidying things up). If a change has to be made I would suggest the
> one below. However this would mean going through all the errors reported in
> MI to work out which ones need mi_error_message but currently use error (),
> e.g., "mi_cmd_stack_list_locals: Usage: PRINT_VALUES".
>

The log stream output doesn't have any token associated, so as we move
to non-stop mode and multi-process debugging, you can't associate
the log stream output with a command, unless the frontend is waiting
for every command to complete before issuing the next -- possibly
to another process or thread. My point of view is that, all
errors comming from gdb for a particular command should be output
to ^error, and should be collected in a batch and output in one
MI line only. We can arrange for the those messages that are only
output to & currently to show up in in ^error channel too. E.g.:

Today:

333-var-create int * int
&"Attempt to use a type name as an expression.\n"
&"mi_cmd_var_create: unable to create variable object\n"
333^error,msg="mi_cmd_var_create: unable to create variable object"
(gdb)

Should be:

333-var-create int * int
333^error,msg="Unable to create variable object.\nAttempt to use a type name
as an expression.\n"
(gdb)

Or, extending MI:

333-var-create int * int
333^error,msg="Unable to create variable object.",reason="Attempt to use a
type name as an expression.\n"
(gdb)

If the frontend/user wants, it can put the msg in from ^error,msg= in the
console too, so there's no loss.

--
Pedro Alves