Re: [RFC PATCH 0/6] uprobes/x86: fix the reprel jmp/call handling

From: Masami Hiramatsu
Date: Tue Apr 08 2014 - 07:44:01 EST


(2014/04/07 5:15), Oleg Nesterov wrote:
> On 04/04, Jim Keniston wrote:
>>
>> On Fri, 2014-04-04 at 21:32 +0200, Oleg Nesterov wrote:
>>>
>>> 1. Why insn_get_displacement() doesn't work? See "HELP!!!"
>>> below.
>>
>> insn->moffset1.value seems to be what you want.
>
> Works! Thanks a lot.
>
> Still I can't understand why displacement.nbytes == 0 in this case...
> Nevermind.

I guess that you misunderstanding what the displacement means.
insn->displacement means what x86 instruction encoding as
"displacement" bytes, which is an extension of addressing mode.

The relative Jumps are JMP(near) which operand is Jz,
and JMP(short) which operand is Jb, according to the Intel SDM 2b
appendix A2.

According to SDM2b A.2.1 and A.2.2, the J means
----
The instruction contains a relative offset to be added to the instruction
pointer register (for example, JMP (0E9), LOOP).
----

and z and b means
----
b Byte, regardless of operand-size attribute.
z Word for 16-bit operand-size or doubleword for 32 or 64-bit operand-size.
----
Ok, so these are have one immediate operand which has 1,2(word),
4(doubleword) bytes.
In that case, you should use insn->immediate, instead of insn->moffset1 which
is only for MOV(A0-A3) on x86-64. (please see Intel SDM2a 2.2.1.4)

Thank you,

> OK. Please see the RFC changes. Obviously not for inclusion yet. And
> totally untested, except I verified that the test-case from 4/6 works.
>
> Please comment.
>
> Oleg.
>
>


--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/