[PATCH] Bail out of processing stop if hook-stop resumes target / changes context

Yao Qi qiyaoltc@gmail.com
Wed Aug 19 08:22:00 GMT 2015


Pedro Alves <palves@redhat.com> writes:

Hi Pedro,

> -  if (stop_command)
> -    catch_errors (hook_stop_stub, stop_command,
> -		  "Error while running hook_stop:\n", RETURN_MASK_ALL);
> +  if (stop_command != NULL)
> +    {
> +      struct stop_context *saved_context = save_stop_context ();
> +      struct cleanup *old_chain
> +	= make_cleanup (release_stop_context_cleanup, saved_context);
> +
> +      catch_errors (hook_stop_stub, stop_command,
> +		    "Error while running hook_stop:\n", RETURN_MASK_ALL);
> +
> +      /* If the stop hook resumes the target, then there's no point in
> +	 trying to notify about the previous stop; its context is
> +	 gone.  Likewise if the command switches thread or inferior --
> +	 the observers would print a stop for the wrong
> +	 thread/inferior.  */
> +      if (stop_context_changed (saved_context))
> +	{
> +	  do_cleanups (old_chain);
> +	  return 1;
> +	}
> +      do_cleanups (old_chain);
> +    }

I am wondering why don't we let interpreter in async to execute
stop_command, and we simply return here.  In this way, we don't have to
know whether stop_command resumes the target or switches the thread.
Once there is no event from event loop, the target really stops and
hook-stop is already executed.

-- 
Yao (齐尧)



More information about the Gdb-patches mailing list