This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] [PATCH 2.6.37-rc5-tip 13/20] 13: x86: x86 specific probe handling
- From: Peter Zijlstra <peterz at infradead dot org>
- To: Roland McGrath <roland at redhat dot com>
- Cc: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>, Ingo Molnar <mingo at elte dot hu>, Steven Rostedt <rostedt at goodmis dot org>, Arnaldo Carvalho de Melo <acme at infradead dot org>, Linus Torvalds <torvalds at linux-foundation dot org>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, Christoph Hellwig <hch at infradead dot org>, Andi Kleen <andi at firstfloor dot org>, Oleg Nesterov <oleg at redhat dot com>, Andrew Morton <akpm at linux-foundation dot org>, SystemTap <systemtap at sources dot redhat dot com>, Jim Keniston <jkenisto at linux dot vnet dot ibm dot com>, Frederic Weisbecker <fweisbec at gmail dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, LKML <linux-kernel at vger dot kernel dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- Date: Fri, 28 Jan 2011 09:36:38 +0100
- Subject: Re: [RFC] [PATCH 2.6.37-rc5-tip 13/20] 13: x86: x86 specific probe handling
- References: <20101216095714.23751.52601.sendpatchset@localhost6.localdomain6> <20101216095947.23751.75003.sendpatchset@localhost6.localdomain6> <1295963783.28776.1061.camel@laptop> <20110127094041.GR19725@linux.vnet.ibm.com> <1296123733.15234.53.camel@laptop> <20110127191146.DB22F180999@magilla.sf.frob.com> <20110128045721.GV19725@linux.vnet.ibm.com> <20110128062316.9515018099A@magilla.sf.frob.com>
On Thu, 2011-01-27 at 22:23 -0800, Roland McGrath wrote:
> > Uprobes doesn't request/handle block-step for now. So can we postpone
> > your suggested changes till uprobes needs to handle block-step?
>
> That's not the issue. The way the hardware works is that if the bit is set
> in the MSR, then the TF eflags bit means block-step instead of single-step.
> So if PTRACE_SINGLEBLOCK has been used (i.e. user_enable_block_step), then
> this can interfere with your use of single-step. You need to do the work
> in the else branch of step.c:enable_step to ensure that the hardware is not
> left in the state where it will do block-step instead of single-step when
> uprobes wants a single-step done.
And reset the hardware back to block step when done, and provide the
actual break blockstep would have.
Suppose you hit a breakpoint on the return path while the user it
debugging in blockstep mode, that should all just work.
So there you trap on the return, switch to single step to execute the
return out of line, when done you need to actually break to userspace
since its the end of a block, as well as reset block mode.