Hi,
I don't think the user can't do any debugging on kernels with KDB
compiled in, because the user can disable KDB by echo "0" to
"/proc/sys/kernel/kdb". The user can switch between KDB and GDB by a command
line. The only problem is that KDB can't work with GDB simultaneously. Does
any user really want to debug his code with KDB and GDB at one time?
Regards.
Sonic Zhang
-----Original Message-----
From: Keith Owens [mailto:[EMAIL PROTECTED]]
Sent: 2003?2?12? 17:43
To: Zhang, Sonic
Cc: KDB (E-mail); WangFrank (E-mail); XieMay (E-mail)
Subject: Re: I fix a bug in kdb-v3.0-2.4.20, which cause the hardware
breakpoi nts fail to work.
On Wed, 12 Feb 2003 17:01:17 +0800,
"Zhang, Sonic" <[EMAIL PROTECTED]> wrote:
> 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.
I tried that in early versions of kdb but the users complained too
much. It meant that they could not do any debugging on kernels with
kdb compiled in.
Both i386 and ia64 can generate traps when a breakpoint is changed.
What about using that trap to detect a change of hardware breakpoint
and rejecting the user request if kdb is already using that breakpoint
register? That would only prevent use of gdb if kdb was actually using
a hardware register, instead of banning all gdb use on a kdb enabled
kernel.
We should also change kdb to use breakpoint registers from the top down
instead of bottom up. That would minimize conflicts with gdb.
