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: Roland McGrath <roland at redhat dot com>
- To: Peter Zijlstra <peterz at infradead dot org>
- 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: Thu, 27 Jan 2011 11:11:46 -0800 (PST)
- 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>
> But I'll leave this to the x86 people who actually know the intricacies
> of the single step cruft, I was just wondering why you weren't using (or
> extending) the existing code.
The hairy aspects of the step.c code are hairy (and not usable at interrupt
level) because they do some instruction analysis. Since uprobes already
does its own instruction analysis, reusing step.c's separate hacks makes
less sense to me than integrating knowledge of the single-step vs
pushf/popf issues into the uprobes instruction analysis.
That said, there is further nontriviality just to do with the block-step
support and with not clobbering user-visible usage of TF in eflags, which
uprobes needs to handle as well. It makes sense to share that code rather
than repeating it, even if that entails changes to the step.c code.
Thanks,
Roland