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 : [EMAIL PROTECTED] Phone : 91-124-6560303, Extn: 744 Keith Owens <[EMAIL PROTECTED]> To: "Zhang, Sonic" <[EMAIL PROTECTED]> Sent by: cc: "KDB (E-mail)" <[EMAIL PROTECTED]>, "WangFrank [EMAIL PROTECTED] (E-mail)" <[EMAIL PROTECTED]>, "XieMay (E-mail)" i.com <[EMAIL PROTECTED]> 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" <[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.
