Messages in this thread Patch in this message | | | Date | Sat, 12 Dec 2015 15:44:59 -0700 | Subject | [PATCH 1/1] Add hw_breakpoint_enable function | From | Jeff Merkey <> |
| |
The current function to manually restore breakpoints (hw_breakpoint_restore) places the contents of the thread.debugreg6 variable back into the dr6 hardware register, a piece of hardware intended to be read, not used as local storage. The problem with this is that systems that register for breakpoints, including the perf event system and kgdb/kdb, modify this variable. I have observed garbage stacked debug statuses being cycled through dr6 and this variable over and over again in a loop by calls to hw_breakpoint_restore() that cause strange behaviors in kdb and this layer. In short, I don't use this broken function.
This function is necessary because upon debugger entry, you must set dr7 to 0 to disable breakpoints while inside the debugger then call hw_breakpoint_restore() to reload the state and re-enable them. This function is identical to hw_breakpoint_restore() except it leaves out writing a user defined thread.debugreg6 variable back into a hardware register not intended for that purpose.
Signed-off-by: Jeff V. Merkey <jeffmerkey@gmail.com> diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c index 50a3fad..7ea0f78 100644 --- a/arch/x86/kernel/hw_breakpoint.c +++ b/arch/x86/kernel/hw_breakpoint.c @@ -425,6 +425,16 @@ void hw_breakpoint_restore(void) } EXPORT_SYMBOL_GPL(hw_breakpoint_restore);
+void hw_breakpoint_enable(void) +{ + set_debugreg(__this_cpu_read(cpu_debugreg[0]), 0); + set_debugreg(__this_cpu_read(cpu_debugreg[1]), 1); + set_debugreg(__this_cpu_read(cpu_debugreg[2]), 2); + set_debugreg(__this_cpu_read(cpu_debugreg[3]), 3); + set_debugreg(__this_cpu_read(cpu_dr7), 7); +} +EXPORT_SYMBOL_GPL(hw_breakpoint_enable); + /* * Handle debug exception notifications. *
| |