test eax, ecx #702

Closed
mrexodia opened this Issue Jun 15, 2016 · 10 comments

Projects

None yet

5 participants

@mrexodia mrexodia added a commit to mrexodia/capstone that referenced this issue Dec 16, 2016
@mrexodia mrexodia added regression test for issue #702 972a6a6
@mrexodia mrexodia referenced this issue in x64dbg/x64dbg Dec 16, 2016
Closed

Error in Test Instruction #1378

@mrexodia mrexodia added a commit to x64dbg/capstone_wrapper that referenced this issue Dec 16, 2016
@mrexodia mrexodia Nasty workaround for aquynh/capstone#702 33fe8d4
@mrexodia mrexodia added a commit to x64dbg/x64dbg that referenced this issue Dec 16, 2016
@mrexodia mrexodia DBG+GUI: nasty workaround for aquynh/capstone#702 4f5f31b
@bSr43
bSr43 commented Dec 28, 2016

If you want a cleaner fix, you can proceed to these modifications in the file X86GenDisassemblerTables.inc:

  • line 18923, change 88 to 87 (instruction TEST8rr)
  • line 18835, change 69 to 73 (instruction TEST16rr)
  • line 18863, change 69 to 73 (instruction TEST32rr)
  • line 18891, change 43 to 76 (instruction TEST64rr)

It will change the operand specifier to the proper one, where the operands are inverted.

Sorry for not providing the DIFF, it is not possible for me right now 😊

@mrexodia
Contributor
@mrexodia
Contributor

@aquynh what are those files generated from? Perhaps it's better to change the source since the _reduce.inc has different constants for those instructions...

@ant1
ant1 commented Jan 2, 2017

It seems those files are generated by llvm-tblgen, and the bug was fixed in llvm r233686

http://llvm.org/viewvc/llvm-project?view=revision&revision=233686
https://llvm.org/bugs/show_bug.cgi?id=22995

@aquynh
Owner
aquynh commented Jan 2, 2017

fixed now, please confirm.

@mrexodia
Contributor
mrexodia commented Jan 3, 2017

Works correctly now, thanks a lot!

test eax, ecx

@mrexodia mrexodia closed this Jan 3, 2017
@radare
Contributor
radare commented Jan 3, 2017

in r2 we had this issue opened for more than a year. now we can close it too. thanks, any will in releasing capstone during 2017 or should distros and users be forced to use the code from git one year more?

@aquynh
Owner
aquynh commented Jan 3, 2017

yes, the plan is to merge https://github.com/aquynh/capstone/tree/encoding into "next", then we can go for v4.0. however, this would break all the bindings, that is my concern now.

@mrexodia
Contributor
mrexodia commented Jan 3, 2017
@radare
Contributor
radare commented Jan 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment