From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22598 invoked by alias); 26 Aug 2011 13:17:38 -0000 Received: (qmail 22590 invoked by uid 22791); 26 Aug 2011 13:17:37 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Aug 2011 13:17:09 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7QDH2jx025496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Aug 2011 09:17:02 -0400 Received: from host1.jankratochvil.net (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7QDH0cZ023560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2011 09:17:02 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p7QDGxvk005448; Fri, 26 Aug 2011 15:16:59 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p7QDGw2n005447; Fri, 26 Aug 2011 15:16:58 +0200 Date: Fri, 26 Aug 2011 13:17:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [patch 2/2] Do not bpstat_clear_actions on throw_exception #3 Message-ID: <20110826131658.GA1741@host1.jankratochvil.net> References: <20110822145150.GB11817@host1.jankratochvil.net> <201108241119.03993.pedro@codesourcery.com> <20110826101359.GA27121@host1.jankratochvil.net> <201108261245.32822.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108261245.32822.pedro@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2011-08/txt/msg00490.txt.bz2 On Fri, 26 Aug 2011 13:45:32 +0200, Pedro Alves wrote: > We're not terribly consistent in the printing stuff --- in some cases > we end up showing that "", while in > other cases we let the error escape, like in "p *0". + > I'd find it wrong that a command sequence continues > blindly ignoring previous errors by default. The problem is this "inconsistence" affects when the command sequences break vs. when they continue. What about save_gdb_index_command TRY_CATCH there? TRY_CATCH + exception_fprintf Error while writing index for `objfile->name': except.message This means the command succeeds even if some .gdb_index files could not be produced. I guess in this case there should have been rather final throw_error so that save_gdb_index_command as whole throws one exception. But it is a nice direction that any command with uncaught exception should stop execution + clear all bpstats. And any command that has all the exceptions caught should continue execution + must not clear any bpstats. Whatever violates these rules is a bug in the command implementation and not in the GDB scripts execution control. > I think the neatest fix would be to add some try/catch/finaly > syntax to the cli. There was a patch for that posted eons ago: > > http://sourceware.org/ml/gdb-patches/2001-12/msg00449.html I find this more as obsolete now, for advanced scripting there is already Python or a control via MI by Perl, it does not make sense to further extend the canned sequences of commands. > I think most if not all those changes are actually bug fixes. + > I agree it's a bug. The backtrace stopped gracefully, and completed, > it didn't throw any error back to the interpreter. I was considered any change to be a regression; great if it is the opposite. > But we're so close to having this fixed! :-( Did you find some > legitimate use case the patch breaks? For example it changes the tracepoint example but it is great if it is considered a bugfix. It will also execute more bpstats now but therefore it is not a bug but a feature. In fact it also unifies the conditions under which bpstats gets clear and canned commands sequence gets aborted. > > (b) bpstat_clear_actions should also abort script_from_file. > > Hmm? Currently a caught exception: Calls bpstat_clear_actions but it continues execution of script_from_file. and uncaught exception: Calls bpstat_clear_actions and also abort execution of script_from_file. I was proposing that any exception - even the caught one should: Call bpstat_clear_actions and also abort execution of script_from_file. You are proposing and I am going to follow that a caught exception: Does not call bpstat_clear_actions, it continues execution of script_from_file. while an uncaught exception: Call bpstat_clear_actions and also abort execution of script_from_file. My goal was to unify bpstat_clear_actions and script_from_file abortion which gets accomplished also with your proposal. > > (c) There should be a new setting "set error-stops-script" with default "on" > > (backward compatibility) where "off" would disable bpstat_clear_actions > > completely. And I will happily use "set error-stops-script off" in my > > ~/.gdbinit so that I can finally run `gdb -nx -x ./transcript.1'. > > Some patch for something like that has been posted before too: > > This simple patch looks cooked almost in acceptable state, I will hopefully finish / check it in to make the testsuite more debuggable. Thanks, Jan