From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30426 invoked by alias); 25 May 2006 04:16:14 -0000 Received: (qmail 30417 invoked by uid 22791); 25 May 2006 04:16:13 -0000 X-Spam-Check-By: sourceware.org Received: from ausmtp05.au.ibm.com (HELO ausmtp05.au.ibm.com) (202.81.18.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 May 2006 04:16:08 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp05.au.ibm.com (8.13.6/8.13.6) with ESMTP id k4P3oEkU6721768 for ; Thu, 25 May 2006 13:50:14 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4P3oLEf220544 for ; Thu, 25 May 2006 13:50:21 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4P3l0I3011253 for ; Thu, 25 May 2006 13:47:00 +1000 Received: from [9.181.133.48] ([9.181.133.48]) by d23av04.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4P3kwPK011031; Thu, 25 May 2006 13:46:59 +1000 Date: Thu, 25 May 2006 12:07:00 -0000 From: Wu Zhou To: Daniel Jacobowitz cc: gdb@sourceware.org Subject: Re: expected behavior when a signal is sent to the ptraced child In-Reply-To: <20060525032939.GA18883@nevyn.them.org> Message-ID: References: <20060525032939.GA18883@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00367.txt.bz2 Hi Daniel, On Wed, 24 May 2006, Daniel Jacobowitz wrote: > On Thu, May 25, 2006 at 10:36:37AM +0800, Wu Zhou wrote: > > It will stop instead. then the wait function of the prarent (in our case, > > GDB) will return and get the control. It can inspect the status of the > > child and know what cause the child to stop. Then gdb can let the child > > continue using PTRACE_CONT, in this it can choose to delieve the signal on > > to the child, and also ignore it, and even deliver a different signal. > > Yes. Thanks for the confirmation. > > > If my understanding is correct. Then a follow up question is how to make > > the child not to call its signal handler and to stop instead. The reason > > I ask this is that with one kernel, I get different result than the above > > with the following test code: > > If the child receives a signal, it will stop. It looks to me as if > your kernel is not generating the signal in the normal way, i.e. > somehow bypassing normal delivery. In this testcase, the child enters into the signal handler and then it continues its execution until its end. The parent get the control then. I guess you are right, the kernel guy I am working with might use a non-normal way to generate the signal. I need to confirm with him about that though. Thanks for your quick answer! - Wu Zhou