Bug in signal.c or misusing Insight?

[Mark Kettenis]

   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