From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19682 invoked by alias); 1 Apr 2008 00:18:44 -0000 Received: (qmail 19673 invoked by uid 22791); 1 Apr 2008 00:18:44 -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, 01 Apr 2008 00:18:26 +0000 Received: (qmail 8051 invoked from network); 1 Apr 2008 00:18:23 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Apr 2008 00:18:23 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: cleanup mi error message handling Date: Tue, 01 Apr 2008 00:18:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: Nick Roberts , Vladimir Prus , gdb-patches@sources.redhat.com References: <200803241830.11759.pedro@codesourcery.com> <200803301005.39285.ghost@cs.msu.su> <18416.13342.147430.549879@kahikatea.snap.net.nz> In-Reply-To: <18416.13342.147430.549879@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: <200804010118.22536.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-04/txt/msg00000.txt.bz2 Message-ID: <20080401001800.mwjJF0UC4cOQ9gulLMMVlNb2b-kSgxTz7krRr9ZsP8I@z> 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