> I think the best approach will be not to reset dr7 at all. Then there
> won't be any need to worry about restoring it. Leaving a userspace
> watchpoint enabled while running in the kernel ought not to matter; a
> system call shouldn't touch any address in userspace more than once or
> twice
On Thu, 22 Feb 2007, Roland McGrath wrote:
> > Yes, you are wrong -- although perhaps you shouldn't be.
> >
> > The current version of do_debug() clears dr7 when a debug interrupt is
> > fielded. As a result, if a system call touches two watchpoint addresses
> > in userspace only the first acc
> Yes, you are wrong -- although perhaps you shouldn't be.
>
> The current version of do_debug() clears dr7 when a debug interrupt is
> fielded. As a result, if a system call touches two watchpoint addresses
> in userspace only the first access will be noticed.
Ah, I see. I think it would ind
On Wed, Feb 21, 2007 at 03:35:13PM -0500, Alan Stern wrote:
> Going back to something you mentioned earlier...
>
[...]
> On Fri, 9 Feb 2007, Roland McGrath wrote:
> There are two things I am uncertain about: vm86 mode and kprobes. I don't
> know anything about how either of them works. Judging f
Going back to something you mentioned earlier...
On Fri, 9 Feb 2007, Roland McGrath wrote:
> I don't think I really object to the ABI change of clearing %dr6 after an
> exception so that it does not accumulate multiple results. But first I'll
> have to convince myself that we never actually do w
> How do you suggest this be handled? Maybe we should just keep track of a
> maximum user priority level for each slot, allowing it to go up but not
> down until all user processes have given up the slot. (I.e., in the
> example above the later kwatch requests would still fail because we would
>
On Fri, 9 Feb 2007, Roland McGrath wrote:
> I don't think I really object to the ABI change of clearing %dr6 after an
> exception so that it does not accumulate multiple results. But first I'll
> have to convince myself that we never actually do want to accumulate
> multiple results. Hmm, I thin
> Yes. In fact, the current existing code does not handle dr6 correctly.
> It never clears the register, which means you're likely to get into
> trouble when multiple breakpoints (or watchpoints) are enabled.
This is a subtle change from the existing ABI, in which userland has to
clear %dr6 vi
On Fri, 9 Feb 2007, Roland McGrath wrote:
> > All right. However this means thread_struct will have to grow in order to
> > hold each task's debug-register allocations and priorities. Would that be
> > acceptable? (This might be a good reason to keep the number of bits
> > down.)
>
> Well, noo
> All right. However this means thread_struct will have to grow in order to
> hold each task's debug-register allocations and priorities. Would that be
> acceptable? (This might be a good reason to keep the number of bits
> down.)
Well, noone seems to mind the wasted debugreg[5..6] words. ;-)
On 2/7/07, Alan Stern <[EMAIL PROTECTED]> wrote:
I wonder where this convention of using lower numbers to indicate higher
priorities comes from... It seems to be quite prevalent even though it's
obviously backwards.
I agree but at least in the case of 'nice' it works in the sense that
the valu
On Tue, 6 Feb 2007, Roland McGrath wrote:
> > So for the sake of argument, let's assume that debug registers can be
> > assigned with priority values ranging from 0 to 7 (overkill, but who
> > cares?). By fiat, ptrace assignments use priority 4. Then kwatch callers
> > can request whatever pr
> That's good. So I'll assume an updated version of kwatch can be submitted
> without regard to the progress of utrace (other than minor conflicts over
> the exact location of the ptrace code to change).
Indeed.
> Right. I had been thinking in terms of a developer using kwatch to track
> dow
On Mon, 5 Feb 2007, Roland McGrath wrote:
> Sorry I've been slow in giving you feedback on kwatch.
No problem (I have plenty of other things to work on!), and thanks for the
detailed reply.
> > I'll be happy to move this over to the utrace setting, once it is merged.
> > Do you think it would
Sorry I've been slow in giving you feedback on kwatch.
> I'll be happy to move this over to the utrace setting, once it is merged.
> Do you think it would be better to include the current version of kwatch
> now or to wait for utrace?
>
> Roland, is there a schedule for when you plan to get ut
On Thu, Jan 18, 2007 at 08:31:59AM +0100, Ingo Molnar wrote:
>
> * Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > > I'll be happy to move this over to the utrace setting, once it is
> > > merged. Do you think it would be better to include the current
> > > version of kwatch now or to wait
On Thu, 18 Jan 2007, Ingo Molnar wrote:
>
> * Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > > I'll be happy to move this over to the utrace setting, once it is
> > > merged. Do you think it would be better to include the current
> > > version of kwatch now or to wait for utrace?
> > >
>
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > I'll be happy to move this over to the utrace setting, once it is
> > merged. Do you think it would be better to include the current
> > version of kwatch now or to wait for utrace?
> >
> > Roland, is there a schedule for when you plan to get
On Wed, Jan 17, 2007 at 11:17:37AM -0500, Alan Stern wrote:
> I'll be happy to move this over to the utrace setting, once it is merged.
> Do you think it would be better to include the current version of kwatch
> now or to wait for utrace?
>
> Roland, is there a schedule for when you plan to ge
On Tue, 16 Jan 2007, Christoph Hellwig wrote:
> Fir4st I'd say thanks a lot for forward-porting this, it's really useful
> feature for all kinds of nasty debugging.
>
> I think you should split this into two patches, one for the debugreg
> infrastructure, and one for the actual kwatch code.
>
>
On Wed, 17 Jan 2007, Ingo Molnar wrote:
> * Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > From: Alan Stern <[EMAIL PROTECTED]>
> >
> > This patch (as839) implements the Kwatch (kernel-space hardware-based
> > watchpoints) API for the i386 architecture. The API is explained in
> > the kerneldoc
* Alan Stern <[EMAIL PROTECTED]> wrote:
> From: Alan Stern <[EMAIL PROTECTED]>
>
> This patch (as839) implements the Kwatch (kernel-space hardware-based
> watchpoints) API for the i386 architecture. The API is explained in
> the kerneldoc for register_kwatch() in arch/i386/kernel/kwatch.c.
i
Fir4st I'd say thanks a lot for forward-porting this, it's really useful
feature for all kinds of nasty debugging.
I think you should split this into two patches, one for the debugreg
infrastructure, and one for the actual kwatch code.
Also I think you provide one (or even a few) example wathes f
From: Alan Stern <[EMAIL PROTECTED]>
This patch (as839) implements the Kwatch (kernel-space hardware-based
watchpoints) API for the i386 architecture. The API is explained in
the kerneldoc for register_kwatch() in arch/i386/kernel/kwatch.c.
The original version of the patch was written by Vamsi
24 matches
Mail list logo
