Re: [Patch 00/11] Hardware Breakpoint interfaces

[Alan Stern]

On Sat, 28 Mar 2009, K.Prasad wrote:

> On Wed, Mar 25, 2009 at 03:48:31PM -0400, Alan Stern wrote:
> > > +
> > > +/*
> > > + * Handle debug exception notifications.
> > > + */
> > > +int __kprobes hw_breakpoint_handler(struct die_args *args)
> > > +{
> > > +	int i, rc = NOTIFY_DONE;
> > > +	struct hw_breakpoint *bp;
> > > +	/* The DR6 value is stored in args->err */
> > > +	unsigned long dr7, dr6 = args->err;
> > 
> > Please change this.  (I should have changed it long ago, but I never
> > got around to it.)  Instead of passing the DR6 value in args->err,
> > pass a pointer to the dr6 variable in do_debug().  That way the
> > handler routines can turn off bits in that variable and do_debug() can
> > see which bits remain set at the end.
> > 
> > Of course, this will require a corresponding change to the
> > post_kprobe_handler() routine.
> >
> 
> As I looked at the code with an intention of changing it, I don't find a
> place - in hw_breakpoint_handler() and in functions called by
> kprobe_exceptions_notify() where bits in dr6 are written into.

That's because such writes wouldn't do any good in the old code!  :-)

> The thread-specific thread->debugreg6 is updated with causative bits in
> ptrace_triggered() to help send signals to the user-space. I don't see a
> user for the change you propose.

For each breakpoint where we decide it's a case of lazy DR switching or
we invoke a "triggered" callback, the corresponding bit in dr6 should
be cleared.  This is a way of indicating to do_debug() that the handler 
has taken care of these causes of the exception.

Similarly, the kprobe routine should clear the single-step bit in dr6 
when it handles a single-step exception.  When the notifier chain 
completes, the only bits remaining in dr6 should be for events that 
still need to be handled.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/