> That should work well. But how does the handler know whether a ptrace
> trigger occurred? I can think of several possible ways, none of them
> very attractive. Simply checking the vdr6 value might not work. The
> simplest approach would be to see if the trigger callback address is
> equal to
On Wed, 27 Jun 2007, Roland McGrath wrote:
> In the first battle just to make it compile, the only issue was that you
> assume every machine has TIF_DEBUG, which is in fact an implementation
> detail chosen lately by i386 and x86_64. AFAIK the only reason for it
> there is just to make a cheap te
On Wed, 27 Jun 2007, Roland McGrath wrote:
> I did the first crack at a powerpc port. I'd appreciate your comments on
> this patch. It should not be incorporated, isn't finished, probably breaks
> ptrace, etc. I'm posting it now just to get any thoughts you have raised
> by seeing the second ma
On Wed, 27 Jun 2007, Roland McGrath wrote:
> > In theory we should get an exception with both DR_STEP and DR_TRAPn
> > set, meaning that neither notifier will return NOTIFY_STOP. But if the
> > kprobes handler clears DR_STEP in the DR6 image passed to the
> > hw_breakpoint handler, it should w
I did the first crack at a powerpc port. I'd appreciate your comments on
this patch. It should not be incorporated, isn't finished, probably breaks
ptrace, etc. I'm posting it now just to get any thoughts you have raised
by seeing the second machine share the intended arch-independent code.
I j
> So far this work has all been based on the vanilla kernel. Should I
> switch over to basing it on -mm?
It doesn't much matter at the moment. Sticking with vanilla is the easiest
for you and me testing it right now.
> > Calling send_sigtrap twice during the same exception does happen to be
>
On Tue, 26 Jun 2007, Roland McGrath wrote:
> > Here's the next iteration. The arch-specific parts are now completely
> > encapsulated. validate_settings is in a form which should be workable
> > on all architectures. And the address, length, and type are passed as
> > arguments to register_{
On Tue, 26 Jun 2007, Roland McGrath wrote:
> I needed the attached patch on top of the bptest patch for the current
> code. Btw, that is a very nice little tester!
I had already made some of those changes (the ones needed to make
bptest build with the new hw_breakpoint code). I'll add in the o
> All right, I'll change it. And I'll encapsulate those fields. I still
> think it will accomplish nothing more than hiding some implementation
> details which don't really need to be hidden.
It makes me a little happier, and I at least consider that a substantial
accomplishment. ;-)
> It's
I needed the attached patch on top of the bptest patch for the current
code. Btw, that is a very nice little tester!
Below that is a patch to go on top of your current patch, with x86-64
support. I've only tried a few trivial tests with bptest (including an
8-byte bp), which worked great. It is
On Mon, 25 Jun 2007, Roland McGrath wrote:
> I added this on top of your patch to make it compile (and look a little
> nicer).
> With that, bptest worked nicely.
I'll merge this with the rest of the patch.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Mon, 25 Jun 2007, Roland McGrath wrote:
> > "A waste to store one"? Waste of what? It isn't a waste of space; the
> > space would otherwise be unused. Waste of an instruction, perhaps.
>
> Yes.
Of course, calling register_kernel_hw_breakpoint() with three extra
arguments is a waste of a
I added this on top of your patch to make it compile (and look a little nicer).
With that, bptest worked nicely.
---
arch/i386/kernel/kprobes.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
Index: b/arch/i386/kernel/kprobes.c
===
> "A waste to store one"? Waste of what? It isn't a waste of space; the
> space would otherwise be unused. Waste of an instruction, perhaps.
Yes.
> It is now possible for an implementation to store things in a
> machine-dependent fashion; I have added accessor routines as you
> suggested.
> I really don't understand your point here. What's wrong with bp_show?
> Is it all the preprocessor conditionals? I thought that was how we had
> agreed portable code should determine which types and lengths were
> supported on a particular architecture.
That part is fine. The problem is f
> > This does not happen in reality. Breakpoints can only be set by the
> > debugger, not by the program itself. The debugger should always eat the
> > trap.
>
> Hmmm. I put in a little extra code to account for the possibility that
> a program might want to set hardware breakpoints in itself.
On Sun, 13 May 2007, Roland McGrath wrote:
> You may need some memory barriers around the switching/restart stuff.
> In fact, I think it would be better not to delve into reinventing the
> low-level bits there at all. Instead use read_seqcount_retry there
> (linux/seqlock.h). Using that read_seq
On Mon, 14 May 2007, Roland McGrath wrote:
> > It seems to me that signal handlers must run with a copy of the original
> > EFLAGS stored on the stack.
>
> Of course. I'm talking about how the registers get changed to set up the
> signal handler to start running, not how the interrupted register
> It seems to me that signal handlers must run with a copy of the original
> EFLAGS stored on the stack.
Of course. I'm talking about how the registers get changed to set up the
signal handler to start running, not how the interrupted registers are
saved on the user stack. There is no issue with
On Sun, 13 May 2007, Roland McGrath wrote:
> This makes me think about RF a little more. If you ever set it, there are
> some places we need to clear it too. That is, when the PC is being changed
> before returning to user mode, which is in signals and in ptrace. If the
> PC is changing to othe
Sorry again about the delay.
> I trust we are moving closer to a final, usable form.
Indeed, I think it is getting there.
> I think there are probably still a few small things wrong with it. For
> instance, the RF setting isn't right; I misunderstood the Intel manual.
> It should get set on
On Wed, 28 Mar 2007, Roland McGrath wrote:
> Sorry I've been slow in responding to your most recent version.
> I fell into a large hole and couldn't get out until I fixed some bugs.
Has the same thing happened again? There hasn't been any feedback on the
most recent version of hw_breakpoint ema
On Wed, 28 Mar 2007, Roland McGrath wrote:
> Sorry I've been slow in responding to your most recent version.
> I fell into a large hole and couldn't get out until I fixed some bugs.
That's okay; the same thing happens to everyone from time to time.
> > No, I'm not confused and neither are you.
Sorry I've been slow in responding to your most recent version.
I fell into a large hole and couldn't get out until I fixed some bugs.
> No, I'm not confused and neither are you. I realize there's no functional
> difference between the two sets of enable bits, since Linux doesn't use
> hardware
On Tue, 13 Mar 2007, Roland McGrath wrote:
> > Yes, the code could be reworked by moving some of the data from the CPU
> > hw-breakpoint info into the thread's info. I'll see how much simpler it
> > ends up being.
>
> I don't quite understand that characterization of the kind of change I'm
> adv
> Yes, the code could be reworked by moving some of the data from the CPU
> hw-breakpoint info into the thread's info. I'll see how much simpler it
> ends up being.
I don't quite understand that characterization of the kind of change I'm
advocating. If the common case path in context switch has
On Tue, 13 Mar 2007, Roland McGrath wrote:
> > At that moment D, running on CPU 1, decides to unregister a breakpoint in
> > T. Clearing TIF_DEBUG now doesn't do any good -- it's too late; CPU 0 has
> > already tested it. CPU 1 goes in and alters the user breakpoint data,
> > maybe even dealloca
On Tue, 13 Mar 2007 01:00:50 -0700 (PDT)
Roland McGrath <[EMAIL PROTECTED]> wrote:
> > Well, I can add in the test for 0, but finding the set of always-on bits
> > in DR6 will have to be done separately. Isn't it possible that different
> > CPUs could have different bits?
>
> I don't know, but i
> Well, I can add in the test for 0, but finding the set of always-on bits
> in DR6 will have to be done separately. Isn't it possible that different
> CPUs could have different bits?
I don't know, but it seems unlikely. AFAIK all CPUs are presumed to have
the same CPUID results, for example.
>
> That sounds like a rather fragile approach to avoiding a minimal amount of
> work. Debug exceptions don't occur very often, and when they do it won't
> matter too much if we go through some extra notifier-chain callouts.
When single-stepping occurs it happens repeatedly many times, and that
d
On Tue, 6 Mar 2007, Roland McGrath wrote:
> > > Yeah, I guess that's right. It should still return NOTIFY_STOP when
> > > args->err has no other bits set, so notifiers aren't called with zero.
> >
> > In practice that might not work. On my machine, at least, reads of DR6
> > return ones in all
> > Yeah, I guess that's right. It should still return NOTIFY_STOP when
> > args->err has no other bits set, so notifiers aren't called with zero.
>
> In practice that might not work. On my machine, at least, reads of DR6
> return ones in all the reserved bit positions.
Does that mean asm("mov
On Mon, 5 Mar 2007, Roland McGrath wrote:
> > The actual guarantee I need is that nobody will switch_to() the task while
> > my routines are running.
>
> You can't get that. It can always be woken for SIGKILL (which is a good
> thing). What you are guaranteed is that if it does, it will never r
> Presumably you mean that hw-breakpoint.c shouldn't do anything at all on
> single-step exceptions.
Right.
> So far I've been developing under 2.6.21-rc, which doesn't have utrace.
> But eventually this will be submitted by way of -mm, which does. The
> easiest approach would be to make the w
> > Please not. That might save a few bytes, but it makes the interface a
> > lot harder to understand for users. We really discourage over-loaded
> > interfaces in Linux.
>
> I agree with Christoph. Plenty of other interfaces in the kernel do the
> same thing.
I don't think a single hook for
On Sun, 4 Mar 2007, Roland McGrath wrote:
> Thanks, Alan. Great work. I have some suggestions for changes.
>
> > I pretty much copied the existing code for handling vm86 mode
> > and single-step exceptions, without fully understanding it.
> >
> > The code doesn't virtualize the BS
On Mon, Mar 05, 2007 at 11:16:48AM -0500, Alan Stern wrote:
> > Making this unconditional is pointless and just makes things harder to
> > read, so please don't do it. (The same is true for utrace, but Roland
> > has unfortunately still not replied to my mail mentioning it :P)
>
> Sorry, I don't
On Mon, 5 Mar 2007, Christoph Hellwig wrote:
> On Sun, Mar 04, 2007 at 11:01:36PM -0800, Roland McGrath wrote:
> > > The parts relating to kernel breakpoints could be made conditional
> > > on a Kconfig option. The amount of code space saved would be
> > > relatively small; I'm not sure tha
On Sun, Mar 04, 2007 at 11:01:36PM -0800, Roland McGrath wrote:
> > The parts relating to kernel breakpoints could be made conditional
> > on a Kconfig option. The amount of code space saved would be
> > relatively small; I'm not sure that it would be worthwhile.
>
> In a utrace merge
Thanks, Alan. Great work. I have some suggestions for changes.
> I pretty much copied the existing code for handling vm86 mode
> and single-step exceptions, without fully understanding it.
>
> The code doesn't virtualize the BS (single-step) flag in DR6
> for userspace.
40 matches
Mail list logo
