Hi,
I have reported this bug for kdb-v2.5-2.4.19 before. It still exist
in kdb-v3.0-2.4.20.
The following lines are in my former mail.
----------------------------------------------------------------------------
----
Hi,
I find this bug in KDB patch "kdb-v2.5-2.4.19" together with
pristine kernel 2.4.19.
This bug doesn't happen on "bp" or "bpa".
The steps to reproduce:
1. Enter KDB by key "Pause"
2. bph printk (or bpha printk)
3. go
4. insmod testkdb.o ( This is my test module, which prints messages
by "printk" in the initialization routine. Compile file "testkdb.c" before
do the test.)
The result:
Fail to trap into KDB at the breakpoint.
----------------------------------------------------------------------------
----
Now, I find the root cause and attach a patch file for kernel 2.4.20
with kdb-v3.0-2.4.20 patches.
In the signal handler in file "arch/i386/kernel/signal.c", the debug
register dr7 is set with the corresponding field in the task structure of
the current process. This field is used by a user space debugger such as
gdb. It replaces the value set by KDB, which cause the KDB hardware break
point fails to work.
/* Reenable any watchpoints before delivering the
* signal to user space. The processor register will
* have been cleared if the watchpoint triggered
* inside the kernel.
*/
__asm__("movl %0,%%db7" : : "r"
(current->thread.debugreg[7]));
I changed these code lines. I allow the kernel signal handle to
change dr7 only when KDB is in the kernel and the variable kdb_on != 0. That
means KDB can't work together with any user space debugger. The user must
make sure he exit any user space debugger before enable the KDB.
What do you think about my change?
Please refer to the attachment.
Thanks
*************************************
Sonic Zhang
Software Engineer
Intel China Software Lab
Tel: 021-52574545-1667
iNet: 8-752-1667
*************************************
kdb-signal-v3.0-2.4.20-i386-1
Description: Binary data
