Re: [PATCH] Do not respawn signals, take 2.

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Fri, 22 Jun 2012 16:55:25 +0200, Pedro Alves wrote:
> @@ -1950,9 +1954,24 @@ resume_lwp (struct lwp_info *lp, int step)
>  }
>  
>  static int
> -resume_callback (struct lwp_info *lp, void *data)
> +linux_nat_resume_callback (struct lwp_info *lp, void *data)
>  {
> -  resume_lwp (lp, 0);
> +  enum gdb_signal signo = GDB_SIGNAL_0;
> +
> +  if (lp->stopped)
> +    {
> +      struct thread_info *thread;
> +
> +      thread = find_thread_ptid (lp->ptid);
> +      if (thread != NULL)
> +	{
> +	  if (signal_pass_state (thread->suspend.stop_signal))

This signal_pass_state check seems redundant to me.  At least
remote.c append_pending_thread_resumptions does not do the check and infrun.c
already seems to pre-clear it:
  /* If this signal should not be seen by program,
     give it zero.  Used for debugging signals.  */
  else if (!signal_program[tp->suspend.stop_signal])
    tp->suspend.stop_signal = GDB_SIGNAL_0;


> +	    signo = thread->suspend.stop_signal;
> +	  thread->suspend.stop_signal = GDB_SIGNAL_0;
> +	}
> +    }
> +
> +  resume_lwp (lp, 0, signo);
>    return 0;
>  }
>  
[...]
> @@ -2856,6 +2875,8 @@ stop_wait_callback (struct lwp_info *lp, void *data)
>      {
>        int status;
>  
> +      gdb_assert (lp->resumed);
> +
>        status = wait_lwp (lp);
>        if (status == 0)
>  	return 0;

This assertion happens sometimes.
	https://bugzilla.redhat.com/show_bug.cgi?id=808404

The assertion seems right to me, IIRC you also concluded it indicates a Linux
kernel bug where sometimes SIGSTOP is not generated by PTRACE_ATTACH.

Keeping the assertion may give more clue in bugreports when the Linux kernel
bug happens but AFAIK the FSF GDB policy is against such "more assertion for
better bugreports" policy.  But it is also true I do not know what GDB will do
if the kernel bug happens and this assertion is not in place.

Therefore for FSF GDB the general approach is it should be removed.



Thanks,
Jan