Le 14/05/2020 à 14:06, Alistair Popple a écrit :

On Thursday, 14 May 2020 4:11:43 PM AEST Christophe Leroy wrote:

quoted

@@ -249,7 +249,7 @@ int arch_prepare_optimized_kprobe(struct

optimized_kprobe *op, struct kprobe *p)

quoted

* Fixup the template with instructions to:
* 1. load the address of the actual probepoint
*/
-       patch_imm64_load_insns((unsigned long)op, buff + TMPL_OP_IDX);
+       patch_imm64_load_insns((unsigned long)op, 3, buff + TMPL_OP_IDX);

/*
* 2. branch to optimized_callback() and emulate_step()

@@ -282,7 +282,11 @@ int arch_prepare_optimized_kprobe(struct

optimized_kprobe *op, struct kprobe *p) /*
* 3. load instruction to be emulated into relevant register, and
*/
-       patch_imm32_load_insns(*p->ainsn.insn, buff + TMPL_INSN_IDX);
+       temp = ppc_inst_read((struct ppc_inst *)p->ainsn.insn);
+       patch_imm64_load_insns(ppc_inst_val(temp) |
+                              ((u64)ppc_inst_suffix(temp) << 32),
+                              4,

So now we are also using r4 ? Any explanation somewhere on the way it
works ? This change seems unrelated to this patch, nothing in the
description about it. Can we suddenly use a new register without problem ?

Unless I missed something there is no change in register usage here that I
could see. patch_imm32_load_insns() was/is hardcoded to use register r4.

Ah ... Euh ... Ok I missed the change from patch_imm32_load_insns() to 
patch_imm64_load_insns(), I'll check again.