fix the wrong target address of direct/conditional x86 JUMPs (jmp, je..)

[TartaRikker]

I am not sure that this bug is present in the other architectures, but in x86 if you dont supplied keystone with the correct base address(the address of the first instruction) when you use it as a jit assembler, then you will end up with some wrong jump address in your assembled code.
Your documentation says that base address can be ignored which is completely wrong and this caused me to spend so many hours messing with the core code trying to figure out where the bug is... though I'm fairly new to keystone and completely unfamiliar with the LLVM, I managed to apply some solutions to calculate the target address but it was just so easy to just do what I'm doing in the PR.
in fact you can't calculate target address if you didn't know the address of the jump instruction

[aquynh]

unfortunately, this breaks all the CIs, for example https://travis-ci.org/keystone-engine/keystone/builds/295542838?utm_source=github_status&utm_medium=notification. can you fix that?

[TartaRikker]

Sure

[TartaRikker]

Sorry for that syntax error, I've used git web editor to make those changes which is inefficient. I did it so that I finish quickly but seems I stuck lol

[aquynh]

sorry for the late reply, but do you have any examples with wrong output?

[TartaRikker]

You can easily reproduce this by disassembling an already assembled code that contains a jump instruction and then assemble it again, you'll see that wrong address.

Example:

mov	dword ptr [esi + 0x6c], eax
test	eax, eax
jne	0x1011b930 <----- Note this
mov	eax, dword ptr  [0x101f3458]

The same code assembled with Keystone:

mov	dword ptr [esi + 0x6c], eax
test	eax, eax
jne	0x11029478 <------ Wrong address
mov	eax, dword ptr [0x101f3458]

By using this method of testing I managed to find some other bugs, wrong assembling and some crashes, and since you did not interact with this I had to move on but I'm planning to a project about PPC in the near future and I intend to use Keystone for it, when then I will devote a good time to work on Keystone,
and I will enhance this PR since I know about the temporary memory leak and the wrong calculation issue can come back if you deal with large code,

[aquynh]

trying just one instruction like below, with "kstool"

$ kstool x32 "jne  0x1011b930" 1011b900
jne	0x1011b930 = [ 75 2e ]

confirm with Casptone's cstool:

$ cstool x32 752e 1011b900
1011b900  75 2e               jne	0x1011b930

the result matches, so i dont see anything wrong here.

can you reproduce this issue with "kstool" like above to make it easier to confirm the problem?

[TartaRikker]

hummm... first sorry for being late, second I'm not able to reproduce this using kstool I even do not think that kstool is efficient on heavy testing or bugs tracking the method I talked about are much effective.

Anyways you really need to test that example with "ks_asm" API, one with this PR another without it, but in both cases you have to pass "0" in the third argument.