> 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
>
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
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 access will
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.
> 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
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
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 from
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 indeed
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
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
> 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
>
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
> 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
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,
> 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. ;-)
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 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, noone seems
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 via
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 think
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
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
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 priority
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 value
> 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
>
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
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 be
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
down
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
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 utrace
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?
> > >
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?
Roland, is
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 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
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
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.
* 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 think
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 for
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.
Also I
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 get
* 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 utrace
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
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
46 matches
Mail list logo
