From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 634 invoked by alias); 31 Mar 2008 05:07:39 -0000 Received: (qmail 411 invoked by uid 22791); 31 Mar 2008 05:07:38 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 31 Mar 2008 05:07:20 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1JgCEj-00027n-Qf for gdb-patches@sources.redhat.com; Mon, 31 Mar 2008 09:07:16 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JgCES-00027b-Qi; Mon, 31 Mar 2008 09:06:56 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: cleanup mi error message handling Date: Mon, 31 Mar 2008 05:07:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: 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: quoted-printable Content-Disposition: inline Message-Id: <200803310906.55411.ghost@cs.msu.su> 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/msg00495.txt.bz2 On Monday 31 March 2008 04:45:18 Nick Roberts wrote: > > The only thing from you I can find is: > >=20 > > At other times duplicated error messages are desirable, e.g., > >=20 > > -exec-continue=20 > > ^running > > (gdb)=20 > > &"The program is not being run.\n" > > ^error,msg=3D"The program is not being run." > >=20 > > because the first goes to the console for the user to see, the secon= d to > > the frontend to be handled as appropriate. > >=20 > > You still did not say why showing the error message is console is desi= rable. > > 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. >=20 > I can't understand these sentences. The command -exec-continue won't app= ear in > the console but "The program is not being run." will.=20=20 And what is the possible value of that message to the user? It does not cor= respond to anything user has typed in, and it does not correspond to anything user = sees. It's just a message out of blue sky. If we want the console to be truly useful, it should accept all commands fr= om the user, and print GDB responses, including errors, to those commands. Printing resp= onses to commands implicitly emitted by the frontend does not seem to be the purpose= of the console window. > These `errors' and other=20 > similar ones like "No stack." are reported through error () and are norma= l Gdb > output for the user to see. Currently the console can display such messa= ges by > reading LOG-STREAM-OUTPUT. >=20 > Other errors like: >=20 > (gdb)=20 > -interpreter-exec > ^error,msg=3D"mi_cmd_interpreter_exec: Usage: -interpreter-exec interp co= mmand" > (gdb) >=20 > would be due to a frontend error, so I think it would be probably be best= to > display them elsewhare, e.g., status bar. No proposal to change the ^error is made. > The only way for the frontend to distinguish between the two types of err= or is > if the Gdb developer uses the appropriate mechanism, i.e. error () or > mi_error_message in each case. >=20 > I wouldn't make any changes until a real problem is reported (not just Pe= dro > tidying things up). You make it sound as if code cleanup is something on N-th priority. I don't= think it's so, it's one of the most important things in current GDB, and it also = allows us to identify nonobvious behaviour, such as happened here. > If a change has to be made I would suggest the one below.=20 > However this would mean going through all the errors reported in MI to wo= rk out > which ones need mi_error_message but currently use error (), e.g., > "mi_cmd_stack_list_locals: Usage: PRINT_VALUES". > *** mi-main.c=A0=A0=A031 Mar 2008 12:08:10 +1200=A0=A0=A0=A0=A0=A01.110 > --- mi-main.c=A0=A0=A031 Mar 2008 12:16:01 +1200=A0=A0=A0=A0=A0=A0 > *************** mi_execute_command (char *cmd, int from_ > *** 1260,1278 **** > =A0 =A0=A0=A0=A0=A0=A0 =A0mi_parse_free (command); > =A0 =A0=A0=A0=A0=A0=A0 =A0return; > =A0 =A0=A0=A0=A0=A0=A0} > ! =A0 =A0 =A0 if (result.reason < 0) > ! =A0=A0=A0=A0=A0=A0{ > ! =A0=A0=A0=A0=A0=A0 =A0/* The command execution failed and error() was c= alled > ! =A0=A0=A0=A0=A0=A0 =A0 =A0 somewhere. =A0*/ > ! =A0=A0=A0=A0=A0=A0 =A0fputs_unfiltered (command->token, raw_stdout); > ! =A0=A0=A0=A0=A0=A0 =A0fputs_unfiltered ("^error,msg=3D\"", raw_stdout); > ! =A0=A0=A0=A0=A0=A0 =A0if (result.message =3D=3D NULL) > ! =A0=A0=A0=A0=A0=A0 =A0 =A0fputs_unfiltered ("unknown error", raw_stdout= ); > ! =A0=A0=A0=A0=A0=A0 =A0else > ! =A0=A0=A0=A0=A0=A0 =A0 =A0 =A0fputstr_unfiltered (result.message, '"', = raw_stdout); > ! =A0=A0=A0=A0=A0=A0 =A0fputs_unfiltered ("\"\n", raw_stdout); > ! =A0=A0=A0=A0=A0=A0 =A0mi_out_rewind (uiout); > ! =A0=A0=A0=A0=A0=A0} > =A0 =A0 =A0 =A0 mi_parse_free (command); > =A0 =A0 =A0 } > =A0 > --- 1260,1266 ---- > =A0 =A0=A0=A0=A0=A0=A0 =A0mi_parse_free (command); > =A0 =A0=A0=A0=A0=A0=A0 =A0return; > =A0 =A0=A0=A0=A0=A0=A0} > ! > =A0 =A0 =A0 =A0 mi_parse_free (command); > =A0 =A0 =A0 } > Perhaps not quite this but with a ^done RESULT-RECORD too. So, you are suggesting that if execution of MI command results in an call t= o 'error', we respond with ^done? That does not appear right to me. Surely, an excepti= on thrown during processing of a command means we cannot finish that command, which s= hould be reported to the user. - Volodya