From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9300 invoked by alias); 12 Apr 2008 00:19:13 -0000 Received: (qmail 9291 invoked by uid 22791); 12 Apr 2008 00:19:12 -0000 X-Spam-Check-By: sourceware.org Received: from qmta08.westchester.pa.mail.comcast.net (HELO QMTA08.westchester.pa.mail.comcast.net) (76.96.62.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 12 Apr 2008 00:18:51 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA08.westchester.pa.mail.comcast.net with comcast id CNzy1Z0080cZkys5807S00; Sat, 12 Apr 2008 00:17:40 +0000 Received: from gateway.sf.frob.com ([76.102.158.52]) by OMTA10.westchester.pa.mail.comcast.net with comcast id CQJn1Z00H18718U3W00000; Sat, 12 Apr 2008 00:18:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=Mp8WEBwWbE8A:10 a=EkON7fw8eWMA:10 a=RYFLW6ebtpNBegQnzZ7X4w==:17 a=T9FSMhhNHfym4vZippEA:9 a=QpcFTVzfWwH193cyDcmd5TtVh-4A:4 a=MxZ3bB5I4kYA:10 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 86D8A357B; Fri, 11 Apr 2008 17:18:46 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id 5D18B26FA5E; Fri, 11 Apr 2008 17:18:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Daniel Jacobowitz X-Fcc: ~/Mail/linus Cc: Jan Kratochvil , Doug Evans , GDB Patches , mark.kettenis@xs4all.nl Subject: Re: [patch] Fix Linux attach to signalled/stopped processes In-Reply-To: Daniel Jacobowitz's message of Friday, 11 April 2008 17:02:21 -0400 <20080411210221.GA13599@caradoc.them.org> References: <20080401223012.GA14076@host0.dyn.jankratochvil.net> <20080410153735.GD21662@caradoc.them.org> <20080410154839.GA5375@host0.dyn.jankratochvil.net> <20080410231205.2DBFD26F992@magilla.localdomain> <20080411210221.GA13599@caradoc.them.org> X-Zippy-Says: DON'T go!! I'm not HOWARD COSELL!! I know POLISH JOKES... WAIT!! Don't go!! I AM Howard Cosell!... And I DON'T know Polish jokes!! Message-Id: <20080412001816.5D18B26FA5E@magilla.localdomain> Date: Sat, 12 Apr 2008 16:38:00 -0000 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-04/txt/msg00234.txt.bz2 > PTRACE_KILL; that only sets the exit_code and wakes the process but at PTRACE_KILL is completely useless AFAIK. Sending SIGKILL with kill always works (except in a few buggy kernels from a short window a few years ago). > I feel like there's a kernel bug here somewhere, but it's buried in > the depths of poorly defined ptrace semantics, so maybe not. I think > it prudent not to deliberately put things into the job-control stop > state because of this limitation. There isn't really any entirely satisfactory definition of "right" I can find, because it's just so wrong that the real parent will never see CLD_CONTINUED or CLD_STOPPED indicators no matter what. I gave up on ptrace meaning anything other than whatever it has stably meant for kernels in use for a good while. > What we need is to get from the job control stopped state, back into > the signal delivery stopped state. Jan's artificially delivered > SIGCONT is the only way I can think of to do this. Or you can use any unblocked signal with tkill to get one pending and then PTRACE_CONT,tid,0,0 to force the wakeup. Generating SIGCONT (blocked or not) will wake up all the threads in the process, which may not be what you want. You could use a signal >= SIGRTMIN to get your synthetic one queued separately from any that might already be there, and then recognize yours by si_pid when you see it stop. Thanks, Roland