Le 14/05/2020 à 14:06, Alistair Popple a écrit :
On Thursday, 14 May 2020 4:11:43 PM AEST Christophe Leroy wrote:
@@ -249,7 +249,7 @@ int arch_prepare_optimized_kprobe(struct
optimized_kprobe *op, struct kprobe *p)
* 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.
