Re: [patch 2/2] Do not bpstat_clear_actions on throw_exception #3

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 24 Aug 2011 12:19:03 +0200, Pedro Alves wrote:
> On Tuesday 23 August 2011 21:32:58, Jan Kratochvil wrote:
> > Testing is more difficult, going to post now patch 3/2 but in fact the real
> > continuation is not tested there as the testcase gets caught by
> > execute_command.  I haven't done a proper testcase for the async mode.
> 
> I think a hook-stop that errors would be sufficient to leave
> breakpoint commands dangling (normal_stop is called after
> handle_inferior_event, from fetch_inferior_event)

The problem is from hook-stop one runs execute_command which already catches
the error and does bpstat_clear_actions on its own.

Just FYI, it would be better but not everything needs to have a testcase.


I started this thread to support entry-values-not-available implemented via an
exception.  It may even have been inspired by your NOT_AVAILABLE_ERROR.

When evaluating all TRY_CATCH cases where should be done bpstat_clear_actions
and where not I have found it is very subjective.  gdb_target_find_new_threads
for example may catch exception due to corrupted thread list when analysing
a core file, therefore it currently does bpstat_clear_actions.  But maybe it
was expected the thread list is corrupted (it may have been the reason a core
file got dumped).

bpstat_clear_actions is not so strong as script_from_file abort but I find it
similar and maybe confusing their conditions are not the same.  I find wrong
that `gdb -nx -x ./cmd' stops on first error as I have to run `gdb -nx <cmd'
in such cases while that mode of run has other kinds of disadvantages.

Even if this patch gets fixed the way we were leading to it would still make
changes in GDB behavior as GDB would much less call bpstat_clear_actions.


The tracepoint example below on FSF GDB HEAD does:

Found trace frame 0, tracepoint 4
#0  globals_test_func () at ./gdb.trace/unavailable.cc:319
Backtrace stopped: Not enough registers or memory available to unwind further
No longer looking at any trace frame
(gdb) _

while it does not print "still-executing" which is IMO a bug, do you agree?


If not printing "still-executing" is really a bug proposing to forget about
the current patch and instead to:

(a) throw_exception will call bpstat_clear_actions only if exception.error is
    not NOT_AVAILABLE_ERROR (adding later my new ENTRY_VALUE_NOT_AVAILABLE).

(b) bpstat_clear_actions should also abort script_from_file.

(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'.

I will try to code it.


Thanks,
Jan


cat >cmd <<EOH
file gdb.trace/unavailable
target remote localhost:1234
break begin
break end
commands
  tstop
  tfind start
  bt
  tfind none
end
break end
commands
  echo still-executing\n
end
trace 319
actions
collect a
end
continue
tstart
continue
EOH

./gdbserver --once :1234 ../testsuite/gdb.trace/unavailable
../gdb -nx -x cmd