Perhaps you are already aware of this, but thought I'd mention that the
debug register allocation patch which we used for watchpoint support in
dprobes/kprobes, also addressed this very same problem. It modifies ptrace
and any other facility (e.g dprobes, kdb if present) to use the allocation
interface. It distinguishes between local (per-process) and global (kernel
level - i.e. kdb/dprobes etc) uses of breakpoint registers - allocates
breakpoint registers top down for the global case (like you suggest), and
makes sure that they don't get overwritten during a context switch.
The following link points to a patch for 2.5 kernel, but should be easy to
put up a 2.4 version, if it helps, since its already part of the dprobes
patch we have for 2.4.20 (http://www-124.ibm.com/linux/projects/dprobes/).
http://www-124.ibm.com/linux/patches/?patch_id=703
Regards
Suparna
Suparna Bhattacharya
Linux Technology Center
IBM Software Lab, India
6th floor, DLF Square, Gurgaon
E-mail : bsuparna@xxxxxxxxxx
Phone : 91-124-6560303, Extn: 744
Keith Owens
<kaos@xxxxxxx> To: "Zhang, Sonic"
<sonic.zhang@xxxxxxxxx>
Sent by: cc: "KDB (E-mail)"
<kdb@xxxxxxxxxxx>, "WangFrank
kdb-bounce@xxxxxx (E-mail)"
<frank.wang@xxxxxxxxx>, "XieMay (E-mail)"
i.com <may.xie@xxxxxxxxx>
Subject: Re: I fix a bug in
kdb-v3.0-2.4.20, which cause
the hardware breakpoi nts fail
to work.
02/12/03 03:13 PM
On Wed, 12 Feb 2003 17:01:17 +0800,
"Zhang, Sonic" <sonic.zhang@xxxxxxxxx> 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.
|