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

[Pedro Alves <palves at redhat dot com>]

On 08/19/2015 09:22 AM, Yao Qi wrote:
> 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.

Not sure I understood the suggestion -- I don't see how that would end
up being different.  If the hook-stop does "continue&", then we still need
to know that the target was resumed.  Likewise if the hook-stop just
does "thread N" and thus switches to another thread -- there's no
execution involved in that case so seems to me interpreter async/sync
makes no difference.

Thanks,
Pedro Alves