Re: [PATCH 2/2] [POWERPC] uprobes: powerpc port

On Wed, 2012-06-06 at 15:05 +0530, Ananth N Mavinakayanahalli wrote:

On Wed, Jun 06, 2012 at 11:27:02AM +0200, Peter Zijlstra wrote:

quoted

On Wed, 2012-06-06 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:

quoted

One TODO in this port compared to x86 is the uprobe abort_xol() logic.
x86 depends on the thread_struct.trap_nr (absent in powerpc) to determine
if a signal was caused when the uprobed instruction was single-stepped/
emulated, in which case, we reset the instruction pointer to the probed
address and retry the probe again. 

Another curious difference is that x86 uses an instruction decoder and
contains massive tables to validate we can probe a particular
instruction.

Part of that difference is because the x86 instruction set is a lot more
complex.  Another part is due to the lack, back when the x86 code was
created, of robust handling by uprobes of traps by probed instructions.
So we refused to probe instructions that we knew (or strongly suspected)
would generate traps in user mode -- e.g., privileged instructions,
illegal instructions.  A couple of times we had to "legalize"
instructions or prefixes that we didn't originally expect to encounter.

quoted

Can we probe all possible PPC instructions?

For the kernel, the only ones that are off limits are rfi (return from
interrupt), mtmsr (move to msr). All other instructions can be probed.

Both those instructions are supervisor level, so we won't see them in
userspace at all; so we should be able to probe all user level
instructions.

Presumably rfi or mtmsr could show up in the instruction stream via an
erroneous or mischievous asm statement.  It'd be good to verify that you
handle that gracefully.

I am not aware of specific caveats for vector/altivec instructions;
maybe Paul or Ben are more suitable to comment on that.

Ananth

Jim