Re: expected behavior when a signal is sent to the ptraced child

[Wu Zhou <woodzltc@cn.ibm.com>]

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