Re: [PATCH v3 10/17] Implement all-stop on top of a target running non-stop mode

Yao Qi
2015-04-21T11:09:07Z

Pedro Alves <palves@redhat.com> writes:

> gdb/ChangeLog:
> 2015-04-17 Pedro Alves <palves@redhat.com>
>
> * NEWS: Mention "maint set/show target-non-stop".
> * breakpoint.c (update_global_location_list): Check
> target_is_non_stop_p instead of non_stop.
> * infcmd.c (attach_command_post_wait, attach_command): Likewise.
> * infrun.c (show_can_use_displaced_stepping)
> (can_use_displaced_stepping_p, start_step_over_inferior):
> Likewise.
> (resume): Always resume a single thread if the target is in
> non-stop mode.
> (proceed): Check target_is_non_stop_p instead of non_stop. If in
> all-mode but the target is always in non-stop mode, start all the
^^^^^^^^

all-stop mode.

> (handle_signal_stop) <random signal>: If we get a signal while
> stepping over a breakpoint, and the target is always in non-stop
> mode, restart all threads.

> @@ -5614,6 +5666,17 @@ handle_signal_stop (struct execution_control_state *ecs)
> /* Reset trap_expected to ensure breakpoints are re-inserted. */
> ecs->event_thread->control.trap_expected = 0;
>
> + if (!non_stop && target_is_non_stop_p ())
> + {

This path is about the case that a signal is got while in in-line
stepping, isn't? If so, non_stop should be an invariant false. We
don't need to check it.

> + keep_going (ecs);
> +
> + /* We've canceled the step-over temporarily while the
> + signal handler executes. Let other threads run,
> + according to schedlock. */

IMO, we don't need to run other threads according to schedlock. GDB
resumes some threads here and operations should be invisible to user,
schedlock, as a user visible option, shouldn't affect what threads
should be resumed. On the other hand, restart_threads is to undo the
changes done by stop_all_threads, so no user preference (schedlock)
should be considered here.

> + restart_threads (ecs->event_thread);
> + return;
> + }
> +

--
Yao (齐尧)