This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: expected behavior when a signal is sent to the ptraced child
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