From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32506 invoked by alias); 26 Aug 2011 13:51:48 -0000 Received: (qmail 32496 invoked by uid 22791); 26 Aug 2011 13:51:46 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Aug 2011 13:51:19 +0000 Received: (qmail 10913 invoked from network); 26 Aug 2011 13:51:18 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Aug 2011 13:51:18 -0000 From: Pedro Alves To: Jan Kratochvil Subject: Re: [patch 2/2] Do not bpstat_clear_actions on throw_exception #3 Date: Fri, 26 Aug 2011 13:51:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <20110822145150.GB11817@host1.jankratochvil.net> <201108261245.32822.pedro@codesourcery.com> <20110826131658.GA1741@host1.jankratochvil.net> In-Reply-To: <20110826131658.GA1741@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108261451.15850.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: 2011-08/txt/msg00492.txt.bz2 On Friday 26 August 2011 14:16:58, Jan Kratochvil wrote: > 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. Yeah, this one's not clear. The command loops over all objfiles, so some indexes may have been written. Maybe it's a matter of documenting the behavior. > 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. Exactly. > > 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 don't agree, but I'm not going to pursue it either now. I did have a dream of replacing the whole CLI implentation by a tcl based one (since the syntax is quite similar) sometime ago. :-) > > > (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. Great, thanks. > > > (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. -- Pedro Alves