The following patch is for the 2.6.12-rc5-mm1 + my previous
"Kprobes ia64 cleanup" patch that fixes a bug where a kprobe still
fires when the instruction is predicated off. So given the p6=0,
and we have an instruction like:
(p6) move loc1=0
we should not be triggering the kprobe. This is handled by carrying over
the qp section of the original instruction into the break instruction.
--rusty
signed-off-by: Anil S Keshavamurthy <[email protected]>
signed-off-by: Rusty Lynch <[email protected]>
arch/ia64/kernel/kprobes.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.12-rc5/arch/ia64/kernel/kprobes.c
===================================================================
--- linux-2.6.12-rc5.orig/arch/ia64/kernel/kprobes.c
+++ linux-2.6.12-rc5/arch/ia64/kernel/kprobes.c
@@ -115,19 +115,19 @@ int arch_prepare_kprobe(struct kprobe *p
case 0:
major_opcode = (bundle->quad0.slot0 >> SLOT0_OPCODE_SHIFT);
kprobe_inst = bundle->quad0.slot0;
- bundle->quad0.slot0 = BREAK_INST;
+ bundle->quad0.slot0 = BREAK_INST | (0x3f & kprobe_inst);
break;
case 1:
major_opcode = (bundle->quad1.slot1_p1 >> SLOT1_p1_OPCODE_SHIFT);
kprobe_inst = (bundle->quad0.slot1_p0 |
(bundle->quad1.slot1_p1 << (64-46)));
- bundle->quad0.slot1_p0 = BREAK_INST;
+ bundle->quad0.slot1_p0 = BREAK_INST | (0x3f & kprobe_inst);
bundle->quad1.slot1_p1 = (BREAK_INST >> (64-46));
break;
case 2:
major_opcode = (bundle->quad1.slot2 >> SLOT2_OPCODE_SHIFT);
kprobe_inst = bundle->quad1.slot2;
- bundle->quad1.slot2 = BREAK_INST;
+ bundle->quad1.slot2 = BREAK_INST | (0x3f & kprobe_inst);
break;
}
>>>>> On Thu, 26 May 2005 10:51:45 -0700, Rusty Lynch <[email protected]> said:
Rusty> The following patch is for the 2.6.12-rc5-mm1 + my previous
Rusty> "Kprobes ia64 cleanup" patch that fixes a bug where a kprobe still
Rusty> fires when the instruction is predicated off. So given the p6=0,
Rusty> and we have an instruction like:
Rusty> (p6) move loc1=0
Rusty> we should not be triggering the kprobe. This is handled by
Rusty> carrying over the qp section of the original instruction into
Rusty> the break instruction.
What about:
(p6) cmp.eq.unc p9,p10=rX,rY
would the code handle that right? Similary, you may want to check for
the correct handling of instructions that cannot be predicated (such
as "cover").
--david
>>>>>> On Thu, 26 May 2005 10:51:45 -0700, Rusty Lynch
><[email protected]> said:
>
> Rusty> The following patch is for the 2.6.12-rc5-mm1 + my previous
> Rusty> "Kprobes ia64 cleanup" patch that fixes a bug where a kprobe
still
> Rusty> fires when the instruction is predicated off. So given the
p6=0,
> Rusty> and we have an instruction like:
>
> Rusty> (p6) move loc1=0
>
> Rusty> we should not be triggering the kprobe. This is handled by
> Rusty> carrying over the qp section of the original instruction into
> Rusty> the break instruction.
>
>What about:
>
> (p6) cmp.eq.unc p9,p10=rX,rY
>
>would the code handle that right? Similary, you may want to check for
>the correct handling of instructions that cannot be predicated (such
>as "cover").
>
> --david
Thanks, I need to look into this one. Let me update my test to cover
both of these cases and then take another look at our logic.
--rusty