From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19091 invoked by alias); 24 Mar 2008 22:04:44 -0000 Received: (qmail 19075 invoked by uid 22791); 24 Mar 2008 22:04:43 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Mar 2008 22:04:16 +0000 Received: from kahikatea.snap.net.nz (86.30.255.123.static.snap.net.nz [123.255.30.86]) by viper.snap.net.nz (Postfix) with ESMTP id D66F13D9F6A; Tue, 25 Mar 2008 11:04:12 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 7BDAC8FC6D; Tue, 25 Mar 2008 10:04:03 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18408.9553.683746.929167@kahikatea.snap.net.nz> Date: Mon, 24 Mar 2008 22:04:00 -0000 To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: cleanup mi error message handling In-Reply-To: <200803241830.11759.pedro@codesourcery.com> References: <200803241830.11759.pedro@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.1.92.2 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/msg00368.txt.bz2 > Notice the duplication: > &"The program is not being run.\n" > ^error,msg="The program is not being run." > > I can't find a valid reason for that. > In fact having them display in gdb's output window in a > frontend doesn't help anyone, especially, since ^error is supposed > to be the error output channel. Furthermore, there are a couple > of cases that weren't using the mechanism correctly, as they > were already calling error. > > The attached patch fixes it, and fixes the testsuite to not > expect this duplication. > > -- > Pedro Alves > gdb/ > 2008-03-24 Pedro Alves > > * mi/mi-cmds.h (enum mi_cmd_result): Delete MI_CMD_ERROR. > (mi_error_message): Delete declaration. > * mi/mi-interp.c (mi_cmd_interpreter_exec): Call error instead of > returning MI_CMD_ERROR. > * mi/mi-main.c (mi_error_message): Delete. > (mi_cmd_exec_interrupt): > (mi_cmd_thread_select, mi_cmd_thread_list_ids) > (mi_cmd_thread_info): Call error instead of returning > MI_CMD_ERROR. > (mi_cmd_data_list_register_values): Call error instead of > returning MI_CMD_ERROR. Adapt to new get_register interface. > (get_register): Change return typo to void. Call error instead of > returning MI_CMD_ERROR. > (mi_cmd_data_write_register_values): Call error instead of > returning MI_CMD_ERROR. > (mi_cmd_list_features): Return MI_CMD_DONE. > (captured_mi_execute_command): Remove MI_CMD_ERROR handling. > (mi_execute_command): Always print exceptions with -error. 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); 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) 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. For this reason I would not like to see this patch applied. I have previously suggested changes to MI's error reporting. -- Nick http://www.inet.net.nz/~nickrob