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] Bail out of processing stop if hook-stop resumes target / changes context


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


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