Correcting X86 Imm Size

[NicolasDerumigny]

Correcting non-opened issue: x86 imm size is incorrectly reported (inversion of the first two columns of X86ImmSize.inc).

[gklingler]

Hi! Is any chance that this gets merged?

[kabeor]

@NicolasDerumigny Hello, can you do a comparative test case so that we can see the problem more intuitively?

[NicolasDerumigny]

I am unsure what you mean. Do you want me to implement some checks in tests/test_x86.c to ensure the width is well-reported?

[kabeor]

looks no need. will merge soon. Thanks for your contribution

[trufae]

This commit broke several tests in r2 (radareorg/radare2#19402)

I have compared the results with ghidra, binary ninja and IDA, and capstone is doing wrong after this patch. may be good to add some tests before merging things

[aeflores]

yeah, this broke some test for us too.
As an example:

./cstool -d x64 4883e4f0
 0  48 83 e4 f0                                      and        rsp, 0xf0

This is after the change, but it is supposed to be (it is and rsp, -16):

 0  48 83 e4 f0                                      and        rsp, 0xfffffffffffffff0

this is X86_AND64ri8 with encoding size 1 and operand size 8. so: {1, 8, X86_AND64ri8}, rather than {8, 1, X86_AND64ri8},

[NicolasDerumigny]

I am sorry for this bug, I am using capstone as a dependency and needed this patch so that the immediate size was correctly reported; I am trying to find exactly the example where this was needed and will reply as soon as I have found it.

[NicolasDerumigny]

Okey, I believe this MR is utter garbage.

My issue was that cs_x86_op that are immediate seems to have a wrong size attribute (I am looking for the immediate size), and this inversion was providing me with accurate values. However, it is highly possible that I did not fully understood what I was doing, and then submit this buggy MR. I deeply apologize for the inconvenience and need to dig up further on this.

[kabeor]

revert this first, hope you can fix it

[aquynh]

We need to fix CI asap.