Re: Stop breakpoint commands from poping the target

[Vladimir Prus <vladimir at codesourcery dot com>]

Pedro Alves wrote:

> This patch goes on top of Vladimir's pending async fixes patch.
> 
> commands.exp triggers the problem this patch addresses, in
> async mode.
> 
> In that test, we have a watch on a local variable, and then we
> add a command to that watch to print the local variable's
> value.  When the variable goes out of scope, gdb prints that,
> and also runs the associated commands with the watch.  Since
> the variable is out of scope, and error is thrown.  In sync
> targets, the exception just ends the breakpoints command
> processing, and goes on to proceed with the command loop.  But in
> async mode, the exception ends up in
> inf-loop.c:inferior_event_handler/INF_REG_EVENT, which considers exceptions
> fatal, and pops the target.  The fix is to catch the exception earlier.
> 
> Imagine the following command list associated with a breakpoint:
>   non_existing_command
>   info target
> 
> As and example, in sync mode, trying to execute
> non_existing_command causes an error that stops the
> interpreting of all subsequent commands, hence info target is
> never executed.  The patch installs the same behaviour for
> async targets.
> 
> commands.exp passes cleanly with the linux native async patch
> I'll post next.

Heh, we seem to have a mid-flight collision here -- I've a local
patch moving the call to bpstat_do_actions into 
inferior_event_handler. The call you modify, in 
command_line_handler_continuation, runs for CLI only and it's
quite possible to have commands on breakpoints even if GDB uses
MI on the top level.

But that only chances which line of code must be changed, while
this patch is still needed. One tweak though -- I think it's
better to use TRY_CATCH, not catch_exceptions -- it's just
fewer lines.

- Volodya