This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 10/17] Implement all-stop on top of a target running non-stop mode
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 21 Apr 2015 12:08:50 +0100
- Subject: Re: [PATCH v3 10/17] Implement all-stop on top of a target running non-stop mode
- Authentication-results: sourceware.org; auth=none
- References: <1429267521-21047-1-git-send-email-palves at redhat dot com> <1429267521-21047-11-git-send-email-palves at redhat dot com>
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 (éå)