From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24599 invoked by alias); 7 Jul 2008 18:20:32 -0000 Received: (qmail 24591 invoked by uid 22791); 7 Jul 2008 18:20:31 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Jul 2008 18:20:12 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5A8A498415; Mon, 7 Jul 2008 18:20:10 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 422F79805C; Mon, 7 Jul 2008 18:20:10 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KFvJp-0002N6-L3; Mon, 07 Jul 2008 14:20:09 -0400 Date: Mon, 07 Jul 2008 18:20:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [non-stop] 08/10 linux native support Message-ID: <20080707182009.GE1778@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb-patches@sourceware.org References: <200806152205.49241.pedro@codesourcery.com> <200806252217.25796.pedro@codesourcery.com> <20080625221220.GB5723@caradoc.them.org> <200807020434.50543.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807020434.50543.pedro@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00086.txt.bz2 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