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

Daniel Jacobowitz
2008-07-07T18:20:32Z

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