Bug in signal.c or misusing Insight?

Mark Kettenis kettenis@wins.uva.nl
Sat Jul 22 08:09:00 GMT 2000


   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


More information about the Gdb mailing list