From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31190 invoked by alias); 25 May 2006 03:29:44 -0000 Received: (qmail 31180 invoked by uid 22791); 25 May 2006 03:29:43 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 25 May 2006 03:29:41 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fj6Xb-0004w4-IU; Wed, 24 May 2006 23:29:39 -0400 Date: Thu, 25 May 2006 09:06:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: gdb@sourceware.org Subject: Re: expected behavior when a signal is sent to the ptraced child Message-ID: <20060525032939.GA18883@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 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/msg00366.txt.bz2 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. > 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. -- Daniel Jacobowitz CodeSourcery