On Wed, 2007-09-26 at 22:57 +0530, Ananth N Mavinakayanahalli wrote: > On Wed, Sep 26, 2007 at 12:09:35PM -0400, Avishay Traeger wrote: > > On Wed, 2007-09-26 at 14:33 +0530, Ananth N Mavinakayanahalli wrote: > > > What happens when the "call" is singlestepped is that the instruction > > > pointer is moved to the call target. That explains the lower latency you > > > are seeing. You'll need to do something along the lines I suggested in > > > the earlier mail. > > > > Can you please explain what you mean by this more clearly? I'm not a > > kprobes expert yet. Specifically, using kprobes the way that I did, > > what will the resulting code look like? Also, what do you mean by > > "singlestepped"? > > If you single-step (regs->eflags | TF_MASK in i386) on a call instruction, > you'll end up at the call target; ie., after the post_kprobe_handler() > returns, the instruction pointer will point to the first instruction > of foo(). > > Try printk()ing the instruction pointer(regs) after resume_execution() > in the post_kprobe_handler() in your arch/<arch>/kernel/kprobes.c, you'll > see what I mean. > > And when I say singlestepped, I mean executing one instruction under the > architecture specific single step enable flag - the "trap" flag for i386, > the MSR_SE for powerpc, etc. Evidently, this'll mean single-stepping a > single instruction. > > Ananth
I see - thanks for all your prompt and helpful advice! Avishay - 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/