This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]