From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25575 invoked by alias); 25 Mar 2008 03:52:07 -0000 Received: (qmail 25565 invoked by uid 22791); 25 Mar 2008 03:52:07 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 25 Mar 2008 03:51:44 +0000 Received: (qmail 6980 invoked from network); 25 Mar 2008 03:51:37 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Mar 2008 03:51:37 -0000 From: Pedro Alves To: Nick Roberts Subject: Re: cleanup mi error message handling Date: Tue, 25 Mar 2008 03:52:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sourceware.org References: <200803241830.11759.pedro@codesourcery.com> <18408.9553.683746.929167@kahikatea.snap.net.nz> In-Reply-To: <18408.9553.683746.929167@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803250351.44130.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00378.txt.bz2 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