Re: cleanup mi error message handling

[Pedro Alves <pedro at codesourcery dot com>]

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