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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:18 EST