capstone-engine/capstone

the result of regs_access() is not correct, why?

Gavin0210 opened this issue · 2 comments

the code is in following:

from capstone import *
from capstone.arm64 import *
cs = Cs(CS_ARCH_ARM64, CS_MODE_LITTLE_ENDIAN)
CODE = bytes.fromhex('410280D2')
# CODE=b'\x08\x00\x1f\xd6'
cs = Cs(CS_ARCH_ARM64, CS_MODE_ARM)
cs.detail=True
for i in cs.disasm(CODE, 0):
    print(i.regs_access())
    logger.debug("%x:\t%s\t%s" %(i.address, i.mnemonic, i.op_str))

the bytes convert to arm64 is mov x1, #0x12
the result of print(i.regs_access()) is ([217], [217]), it means the reg x1 has been read and write. Obviously the access of reg x1 is write, no read.
why the rusult of regs_access() is not true?
capstone 5.0.0
python 3.10.8

keenk commented

Probably related to #1774

Without looking I'm not 100% sure, but I'd guess that the python bindings for regs_access() don't call cs_regs_access on the C side. Those registry buffers won't be populated until that call happens.

keenk commented

So I did some more digging, and it appears that the python bindings are indeed calling cs_regs_access.

https://github.com/capstone-engine/capstone/blob/3aff9546cef55c4b85d846fc64959806f584edfe/bindings/python/capstone/__init__.py#LL848C29-L848C29

Went down quite the rabbit trail looking at the .inc files under ARM before realizing that I should have been looking under AArch64.

Finally found that this instruction is influenced by the mapping for AArch64_MOVZxi.

On the machine I was testing on, the mapping contained both read and write, but this appears to have been already been corrected in the current code.

https://github.com/capstone-engine/capstone/blob/3aff9546cef55c4b85d846fc64959806f584edfe/arch/AArch64/AArch64MappingInsnOp.inc#LL13683C1-L13683C1

Note that version 5 spans a fairly long time. I'd recommend downloading the latest next branch, rebuild, reinstall, and see if the problem persists.