From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2859 invoked by alias); 25 Sep 2006 10:52:42 -0000 Received: (qmail 2850 invoked by uid 22791); 25 Sep 2006 10:52:41 -0000 X-Spam-Check-By: sourceware.org Received: from 195.22.55.53.adsl.nextra.cz (HELO host0.dyn.jankratochvil.net) (195.22.55.53) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Sep 2006 10:52:38 +0000 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.13.8/8.13.8) with ESMTP id k8PAqZ9Z012806; Mon, 25 Sep 2006 12:52:35 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.13.8/8.13.8/Submit) id k8PAqZ1f012805; Mon, 25 Sep 2006 12:52:35 +0200 Date: Mon, 25 Sep 2006 10:52:00 -0000 From: Jan Kratochvil To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [patch] Fix attaching to Linux stopped processes Message-ID: <20060925105234.GA12295@host0.dyn.jankratochvil.net> References: <20060917221228.GA17263@host0.dyn.jankratochvil.net> <20060917222622.GA2150@nevyn.them.org> <20060918095331.GA9299@host0.dyn.jankratochvil.net> <200609231736.k8NHabVs010214@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609231736.k8NHabVs010214@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.4.2.2i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00164.txt.bz2 On Sat, 23 Sep 2006 19:36:37 +0200, Mark Kettenis wrote: ... > > Also the patch looks right to me - after `PT_ATTACH' it is appropriate that > > `WSTOPSIG (status)' will report the original signal that stopped process, > > (WSTOPSIG (status) == SIGSTOP) <=> (process was in running/sleeping mode). > > Whoa stop, the status returned by wait(2) doesn't tell you whether a > process is sleeping or running. Traditionally, after invoking > ptrace(PT_ATTACH, ...) the kernel will always respond with a SIGSTOP. > Any information about any previous signals is lost. (Red Hat) kernel 2.6.17-1.2647.fc6 reports SIGSTOP for running processes and 0 for processes already stopped before ptrace(PTRACE_ATTACH). It does not differentiate SIGTTIN vs. SIGSTOP etc., though, as I expected, thanks. I found in POSIX that the waitpid(2) vs. ptrace(2) behavior is underfined: http://www.opengroup.org/onlinepubs/009695399/functions/wait.html Since ptrace() is not part of this volume of IEEE Std 1003.1-2001, [ I did not find any other ptrace(2) on http://www.opengroup.org/ . ] > This all smells like a race condition in the kernel to me. The > linux-nat.c code is quite hairy already. I'd suggest fixing the > kernel rather than adding more workarounds. Do you have some standard/specification to follow? I found more that the WSTOPSIG() _should_ report the specific signal: http://www.scit.wlv.ac.uk/cgi-bin/mansec?3B+wait4 the 8 bits higher up from the low-order 8 bits of w_status contain the number of the signal that caused the process to stop. See ptrace(2) and sigvec(3UCB). Regards, Jan