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
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 <[email protected]>, "Jeff V. Merkey"
<[email protected]> 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: [email protected].
On Wed, 23 Jan 2002 14:00:45 -0700,
"Jeff V. Merkey" <[email protected]> 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.
Keith Owens wrote:
>
> On Wed, 23 Jan 2002 14:00:45 -0700,
> "Jeff V. Merkey" <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/