This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 2/2] Do not bpstat_clear_actions on throw_exception #3
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 "<error reading variable: %s>", 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:
> >
> > <http://sourceware.org/ml/gdb-patches/2005-08/msg00120.html>
>
> This simple patch looks cooked almost in acceptable state, I will hopefully
> finish / check it in to make the testsuite more debuggable.
--
Pedro Alves