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

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

(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@hitachi.com