lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.066 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site