This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Bug in signal.c or misusing Insight?
- To: <gdb at sources dot redhat dot com>
- Subject: Bug in signal.c or misusing Insight?
- From: "Ge Ying-An" <Dr dot Ge at huawei dot com>
- Date: Sat, 22 Jul 2000 09:59:13 +0800
- Reply-To: "Ge Ying-An" <geya at huawei dot com>
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?
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)
In our opinion, the GDB stalled by the heavy burden of schedule, so
when the timer was 100ms or slower, the schedule cost was not so clear,
but when the timer is 10ms, ppc860 seems just count the ticks and
do schedule all the time.
I had sent a mail to Gary (gdt@linuxppc.org), arch/ppc/kernel/signal.c
writer,
but no response yet.
Best wishes,
Ge Ying-An