From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31449 invoked by alias); 12 Dec 2008 21:29:25 -0000 Received: (qmail 31440 invoked by uid 22791); 12 Dec 2008 21:29:24 -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.43rc1) with ESMTP; Fri, 12 Dec 2008 21:28:40 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 359FF1053D; Fri, 12 Dec 2008 21:28:39 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 0E16A10499; Fri, 12 Dec 2008 21:28:39 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LBFYs-0002Os-Gl; Fri, 12 Dec 2008 16:28:38 -0500 Date: Fri, 12 Dec 2008 21:29:00 -0000 From: Daniel Jacobowitz To: Doug Evans Cc: gdb@sourceware.org Subject: Re: gdbserver ptrace not doing waitpid after attaching to threads? Message-ID: <20081212212838.GA8833@caradoc.them.org> Mail-Followup-To: Doug Evans , gdb@sourceware.org References: <20081212211315.57CE01C7A79@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212211315.57CE01C7A79@localhost> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00042.txt.bz2 On Fri, Dec 12, 2008 at 01:13:15PM -0800, Doug Evans wrote: > Why isn't gdbserver waiting for a SIGSTOP after attaching to threads? It's supposed to be. At one point it definitely was, though it might have broken recently and been saved by luck. We attached the thread but did not mark it stopped > I've run gdbserver under strace and see that gdbserver is essentially doing > ptrace (ATTACH), ptrace (SETOPTIONS), ptrace (GETREGS) on threads > with no intervening waitpid. Is this current source? A vaguely current kernel? It shouldn't be doing any ATTACH; instead it should be trusting SETOPTIONS to deliver new threads to it via wait. -- Daniel Jacobowitz CodeSourcery