Messages in this thread | | | Date | Sat, 22 Jul 2000 17:09:14 +0200 | From | Mark Kettenis <> | Subject | Re: Bug in signal.c or misusing Insight? |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |