This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Bug in signal.c or misusing Insight?
- To: geya at huawei dot com
- Subject: Re: Bug in signal.c or misusing Insight?
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Sat, 22 Jul 2000 17:09:14 +0200
- CC: gdb at sources dot redhat dot com, linux-kernel at vger dot rutgers dot edu
- References: <007701bff380$6f8035a0$2a190b0a@huawei.com.cn>
From: "Ge Ying-An" <Dr.Ge@huawei.com>
Date: Sat, 22 Jul 2000 09:59:13 +0800
We're using GDB 5.0 to debug our ppc860 target board by remote/TCP,
the board running Linux and gdbserver. When we debug, we found some
problems. If the board has a timer (10ms) running, the GDB stalled.
At last, we had to modify the arch/ppc/kernel/signal.c and re-compiled
the kernel, then the problem vanished. But we don't sure the side-effect
of this modification, could anyone explain the reason of not doing
this before? Or it's not a bug in signal.c, just misusing Insight?
No, it's just a limitation of the ptrace() debugger interface. What's
happening is that you're firing signals at a speed GDB cannot really handle.
We only changed the arch/ppc/kernel/signal.c, line:379 from
if ((current->flags & PF_PTRACED) && signr != SIGKILL)
to
if ((current->flags & PF_PTRACED) && signr != SIGKILL && signr != SIGALARM)
Your fix makes it indeed possible to debug your application, but also
makes it impossible to catch a SIGALARM in GDB. What's really needed
is a kernel interface to set a mask for signals to be traced. That
way GDB can tell the kernel what signals it's interested in. In that
case, if you know your application uses a high resolution timer, you
could simply tell GDB to ignore SIGALARM.
I've CC'ed the Linux kernel mailing list here. Perhaps someone there
is interested in implementing this?
Mark