[PATCH] kdb/mdb hardware breakpoints broken 2.4.17/18

[PATCH] kdb/mdb hardware breakpoints broken 2.4.17/18

[Jeff V. Merkey]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]



Please find a patch that corrects the problem with hardware 
breakpoints not working with kdb.  I have noticed that gdb uses 
inserted int3 (0xCC) breakpoints (as does kdb) for soft breakpoint
support, so this fix may not affect these programs.  It is not 
clear why every signal handled is writing a 0 t the DR7 register.

Patch submitted to Keith Owens and Linux kernel.

Jeff


[-- Attachment #2: patch-0123.kdb --]
[-- Type: text/plain, Size: 584 bytes --]

diff -Naur ./arch/i386/kernel/signal.c ../linux-new/./arch/i386/kernel/signal.c
--- ./arch/i386/kernel/signal.c	Fri Sep 14 15:15:40 2001
+++ ../linux-new/./arch/i386/kernel/signal.c	Wed Jan 23 13:26:07 2002
@@ -698,7 +698,9 @@
 		 * have been cleared if the watchpoint triggered
 		 * inside the kernel.
 		 */
-		__asm__("movl %0,%%db7"	: : "r" (current->thread.debugreg[7]));
+
+		if (current->thread.debugreg[7])
+		   __asm__("movl %0,%%db7"	: : "r" (current->thread.debugreg[7]));
 
 		/* Whee!  Actually deliver the signal.  */
 		handle_signal(signr, ka, &info, oldset, regs);

Re: [PATCH] kdb/mdb hardware breakpoints broken 2.4.17/18

[Bharata B Rao]

Hi,
This is a problem that comes up when user and kernel debuggers are using
the hardware breakpoints at the sametime. 

1. If more than one kernel debugger is present (for ex: DProbes and kdb),
one can ovewrite the debug register settings of the other.

2. kernel allows the gdb to override the kernel debugger's h/w bps (through
ptrace and by writing the process context dr7 during signal handling -- the
problem observed by you below).

In DProbes we have tried to address this problem by providing a centralized
global debug register allocation scheme. (See the latest DProbes code, at
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes)

In this scheme any debugger (user or kernel) wanting to use a debug register
should first get it allocated for its use. User debuggers do this transparently
using ptrace(allocations using ptrace are local to the process). Interfaces
are provided for kernel debuggers to allocate/free the debug registers on global
basis. DProbes has used this successfully and can interoperate well with gdb.
(Currently gdb is not prepared to handle failures when writing to debug
registers using ptrace, hence for now, users would get non-intuitive error
messages).

Regards,
Bharata.

In article <20020123140045.A17976@vger.timpanogas.org>, "Jeff V. Merkey"
<jmerkey@vger.timpanogas.org> wrote:

> Please find a patch that corrects the problem with hardware breakpoints
> not working with kdb.  I have noticed that gdb uses inserted int3 (0xCC)
> breakpoints (as does kdb) for soft breakpoint support, so this fix may
> not affect these programs.  It is not clear why every signal handled is
> writing a 0 t the DR7 register.  Patch submitted to Keith Owens and
> Linux kernel.  Jeff

-- 
Bharata B Rao,
IBM Linux Technology Center, IBM Software Lab, Bangalore, India.
Ph: 91-80-5044962(5262355 X-3962), Mail: bharata@in.ibm.com.

Re: [PATCH] kdb/mdb hardware breakpoints broken 2.4.17/18

[Keith Owens]

On Wed, 23 Jan 2002 14:00:45 -0700, 
"Jeff V. Merkey" <jmerkey@vger.timpanogas.org> wrote:
>Please find a patch that corrects the problem with hardware 
>breakpoints not working with kdb.  I have noticed that gdb uses 
>inserted int3 (0xCC) breakpoints (as does kdb) for soft breakpoint
>support, so this fix may not affect these programs.  It is not 
>clear why every signal handled is writing a 0 t the DR7 register.

Not a 0, it is %0, gcc asm parameter 0.  There used to be a bug in
ptrace handling where db7 would get cleared in taps.c and would not get
reinstated until one timeslice after the initial trap.  Fixed by James
Cownie in June 2000 by reinstating db7 before passing the signal to
user space.

The conflict with kdb is inherent in the lack of a kernel interface for
assigning debug registers.  gdb/ptrace always uses i386 db4-7 no matter
what kdb is doing.  The kernel always uses db7, even if no tracing is
being done.  If you want to use gdb/ptrace then restrict your kdb usage
to db0-3, without gdb/ptrace kdb can use db0-6.

It would be nice to have a proper debug register function to
automatically detect conflicts and tell one of the debuggers to go
away.   However Linus "I don't want kernel debuggers" Torvalds does not
care about this problem and I don't want the footprint of kdb to be any
bigger than it has to be.  So kdb relies on the user to know which
debug registers then can use.

Re: [PATCH] kdb/mdb hardware breakpoints broken 2.4.17/18

[Suparna Bhattacharya]

Keith Owens wrote:
> 
> On Wed, 23 Jan 2002 14:00:45 -0700,
> "Jeff V. Merkey" <jmerkey@vger.timpanogas.org> wrote:
> >Please find a patch that corrects the problem with hardware
> >breakpoints not working with kdb.  I have noticed that gdb uses
> >inserted int3 (0xCC) breakpoints (as does kdb) for soft breakpoint
> >support, so this fix may not affect these programs.  It is not
> >clear why every signal handled is writing a 0 t the DR7 register.
> 
> Not a 0, it is %0, gcc asm parameter 0.  There used to be a bug in
> ptrace handling where db7 would get cleared in taps.c and would not get
> reinstated until one timeslice after the initial trap.  Fixed by James
> Cownie in June 2000 by reinstating db7 before passing the signal to
> user space.
> 
> The conflict with kdb is inherent in the lack of a kernel interface for
> assigning debug registers.  

As Bharata mentioned this sort of a thing is exactly what we use today 
in dprobes. Guess we could separate out that piece as a patch so you can
take a look. We had posted one long back on this list, but have now
cleaned
up and reorganized it a bit. In fact we've used this for a while for
preparing 
consolidated patches containing both dprobes and kdb, in a way that also
interoperates with gdb (we don't want our watchpoint settings to get
overwritten
on a context switch for example).


>gdb/ptrace always uses i386 db4-7 no matter
> what kdb is doing.  The kernel always uses db7, even if no tracing is
> being done.  If you want to use gdb/ptrace then restrict your kdb usage
> to db0-3, without gdb/ptrace kdb can use db0-6.
> 
> It would be nice to have a proper debug register function to
> automatically detect conflicts and tell one of the debuggers to go
> away.   However Linus "I don't want kernel debuggers" Torvalds does not
> care about this problem and I don't want the footprint of kdb to be any
> bigger than it has to be.  So kdb relies on the user to know which
> debug registers then can use.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/