Re: [non-stop] 08/10 linux native support

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jul 02, 2008 at 04:34:50AM +0100, Pedro Alves wrote:
> @@ -337,7 +337,9 @@ linux_fork_killall (void)
>      {
>        pid = PIDGET (fp->ptid);
>        do {
> -	ptrace (PT_KILL, pid, 0, 0);
> +	/* Use SIGKILL instead of PTRACE_KILL because the former works even
> +	   if the thread is running, while the later doesn't.  */
> +	kill (pid, SIGKILL);
>  	ret = waitpid (pid, &status, 0);
>  	/* We might get a SIGCHLD instead of an exit status.  This is
>  	 aggravated by the first kill above - a child has just

This is OK but if anyone wants to make fork support handle
multi-threaded programs someday we may need to expose kill_lwp.

(We could make fork support work; it's checkpoint support that's
terminally stuck, because of lack of Solaris's rfork.)

> @@ -1720,20 +1811,54 @@ linux_handle_extended_wait (struct lwp_i
>  	  else
>  	    status = 0;
>  
> +#if 0
> +	  /* Make thread_db aware of this thread.  We do this this
> +	     early, so in non-stop mode, threads show up as they're
> +	     created, instead of on next stop, and so that they have
> +	     the correct running state.  thread_db_find_new_threads
> +	     needs a stopped inferior_ptid --- since we know LP is
> +	     stopped, use it this time.  */
> +	  old_chain = save_inferior_ptid ();
> +	  inferior_ptid = lp->ptid;
> +	  lp->stopped = 1;
> +	  target_find_new_threads ();
> +	  do_cleanups (old_chain);
> +	  if (!in_thread_list (new_lp->ptid))
> +#else
> +	  /* "Attach"ing to the parent forces the thread_db target to
> +	     build its private data structures for the parent, which
> +	     may have not had them setup yet.  */
> +	  thread_db_attach_lwp (lp->ptid);
> +	  /* Do the same to the child, which, if thread_db is active,
> +	     adds the child to GDB's thread list.  */
> +	  if (!thread_db_attach_lwp (new_lp->ptid))
> +#endif

This (the thread_db_attach_lwp version) looks reasonable to me.  Ugly,
but reasonable.  Why do we need the parent's data?

> +	    {
> +	      /* We're not using thread_db.  Attach and add it to
> +		 GDB's list.  */
> +	      lin_lwp_attach_lwp (new_lp->ptid);
> +	      target_post_attach (GET_LWP (new_lp->ptid));
> +	      add_thread (new_lp->ptid);
> +	    }
> +

Why do we need to call lin_lwp_attach_lwp?  Won't that try to
PTRACE_ATTACH?  And we've already called add_lwp above.


-- 
Daniel Jacobowitz
CodeSourcery