This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v2 2.6.38-rc8-tip 6/20] 6: x86: analyze instruction and determine fixups.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- Cc: Thomas Gleixner <tglx at linutronix dot de>, Peter Zijlstra <peterz at infradead dot org>, Ingo Molnar <mingo at elte dot hu>, Steven Rostedt <rostedt at goodmis dot org>, Linux-mm <linux-mm at kvack dot org>, Arnaldo Carvalho de Melo <acme at infradead dot org>, Linus Torvalds <torvalds at linux-foundation dot org>, Andi Kleen <andi at firstfloor dot org>, Christoph Hellwig <hch at infradead dot org>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, 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>, 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, 18 Mar 2011 12:10:47 -0700 (PDT)
- Subject: Re: [PATCH v2 2.6.38-rc8-tip 6/20] 6: x86: analyze instruction and determine fixups.
- References: <20110314133403.27435.7901.sendpatchset@localhost6.localdomain6> <20110314133507.27435.71382.sendpatchset@localhost6.localdomain6> <alpine.LFD.2.00.1103151529130.2787@localhost6.localdomain6> <20110318182457.GA24048@linux.vnet.ibm.com> <20110318183629.2AB052C286@topped-with-meat.com> <20110318184922.GA31152@linux.vnet.ibm.com>
> So we rewrite the copy of instruction (stored in XOL) such that it
> accesses its memory operand indirectly thro a scratch register.
> The contents of the scratch register are stored before singlestep and
> restored later.
I see. That should work fine in principle, assuming you use a register
that is not otherwise involved, of course. I hope you arrange to restore
the register if the copied instruction is never run because of a signal or
suchlike. In that case, it's important that the signal context get the
original register and original PC rather than the fiddled state for running
the copy. Likewise, if anyone is inspecting the registers right after the
step.
Thanks,
Roland