search

capstone-engine / capstone

Capstone disassembly/disassembler framework for ARM, ARM64 (ARMv8), Alpha, BPF, Ethereum VM, HPPA, LoongArch, M68K, M680X, Mips, MOS65XX, PPC, RISC-V(rv32G/rv64G), SH, Sparc, SystemZ, TMS320C64X, TriCore, Webassembly, XCore and X86.
http://www.capstone-engine.org
7.51k stars 1.54k forks source link

SystemZ SYSZ_OP_ACREG can be removed #2423

Closed david942j closed 2 weeks ago

david942j commented 2 months ago

It's not really a bug but more like a tech-debt that after PR #1306, all registers in operands are considered as in the same family SYSZ_OP_REG even for the Access Registers. This fact makes the existence of SYSZ_OP_ACREG confusing. One may check the operands against SYSZ_OP_ACREG but it would never match.

From cstool on v4, d7e459d026b19d6c3a7b743bfc475d919ff03f74

cstool/cstool -d sysz 'b24f0078'
 0  b2 4f 00 78        ear      %r7, %a8
        ID: 383 (ear)
        op_count: 2
                operands[0].type: REG = 7
                operands[1].type: ACREG = 8 // <- reports type in SYSZ_OP_ACREG

on v5, 7905571be70b20574331fe25131ad923d64745ab:

cstool/cstool -d sysz 'b24f0078'
 0  b2 4f 00 78        ear      %r7, %a8
        ID: 383 (ear)
        op_count: 2
                operands[0].type: REG = 7
                operands[1].type: REG = a8 // <- type becomes SYSZ_OP_REG

To address this issue the macro SYSZ_OP_ACREG should be remove to prevent confusions.

Rot127 commented 1 month ago

You can open a PR if you want. But the SystemZ module is update next after the testing. So it will be gone soon anyways.