This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cleanup mi error message handling


A Monday 24 March 2008 22:04:01, Nick Roberts wrote:
>  > Notice the duplication:
>  > &"The program is not being run.\n"
>  > ^error,msg="The program is not being run."
>  >
>
> The error message isn't duplicated when MI_CMD_ERROR is used, but the bulk
> of this patch is about removing it.  Duplication comes from the single
> line:
>
>      exception_print (gdb_stderr, result);
>

Yes.  Sorry I didn't explain that right.  I really wrote the patch after
learning about the mi_error_message ugliness.  We already have an error
mechanism, we don't need another.

> in mi_execute_command.
>
> I think sometimes errors are just needed when debugging the frontend, e.g.,
>
>   -thread-select
>   ^error,msg="mi_cmd_thread_select: USAGE: threadnum."
>   (gdb)
>
> where one error message is sufficient.  Here I think Gdb is trying to mimic
> perror by giving the name of the C procedure, but I think it's not
> desirable as this gets printed due to a frontend error, not a Gdb error. 
> So I would like to see:
>
>   -thread-select
>   ^error,msg="USAGE: threadnum."
>   (gdb)
>

I agree with this, and was postponing doing that until after this went in.

But, I don't understand what's the benefit of printing to the error stream
in some cases an not in others.  If this is supposed to not be seen by
the user normally, and principle is seen only by a frontend developer,
why not make it consistent with the other errors?

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

That comes from inflow.c.  There are other cases that aren't
currently consistent, like:

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)

Looks like the same kind of error that you wouldn't want
output to &", but it is...
Shouldn't the "Attempt to..." line also go to ^error?

And, look at mi-cmd-var.c for example, 

enum mi_cmd_result
mi_cmd_var_create (char *command, char **argv, int argc)
{
  CORE_ADDR frameaddr = 0;
  struct varobj *var;
  char *name;
  char *frame;
  char *expr;
  struct cleanup *old_cleanups;
  enum varobj_type var_type;

  if (argc != 3)
    {
      /* mi_error_message = xstrprintf ("mi_cmd_var_create: Usage:
         ...."); return MI_CMD_ERROR; */
      error (_("mi_cmd_var_create: Usage: NAME FRAME EXPRESSION."));
    }

In that file, for example, usage errors are output with error.
In mi-main.c you'll see that they aren't...  And this dates back
to the first revision of the files in public CVS.

Looks like the conversion to error had already started ages ago.
Was MI initialy developed outside of gdb?

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]