arm64 python binding, insn.cc is wrong

[poisonflood]

Work environment

Questions	Answers
System Capstone runs on OS/arch/bits	Linux gentoo 6.15.3-x64v3 #1 SMP PREEMPT_DYNAMIC Tue Jul 8 01:48:29 JST 2025 x86_64 Intel(R) Xeon(R) CPU E5-2696 v4 @ 2.20GHz GenuineIntel GNU/Linux
Capstone module affected	x86_64
Source of Capstone	pip
Version/git commit	v5.0.6

Steps to get the wrong result

with Python

CODE = b'\x90\x90\x90\x90'

md = Cs(CS_ARCH_ARM64, CS_MODE_ARM)
md.detail = True
  
CODE = b'\x00\x98\x03\x54'  # b.eq #0x45264
for insn in md.disasm(CODE, 0):
      print(f"Instruction: {insn.mnemonic} {insn.op_str}")
      print(f"Condition Code: {insn.cc}")

Expected results

It should be:

Instruction: b.eq #0x7300
Condition Code: 0

Wrong(real) results

Instruction: b.eq #0x7300
Condition Code: 1

the cc code should be 0 , when eq. as list below:
AArch64CC_EQ = 0x0
AArch64CC_NE = 0x1
AArch64CC_HS = 0x2
AArch64CC_LO = 0x3
AArch64CC_MI = 0x4
AArch64CC_PL = 0x5
AArch64CC_VS = 0x6
AArch64CC_VC = 0x7
AArch64CC_HI = 0x8
AArch64CC_LS = 0x9
AArch64CC_GE = 0xa
AArch64CC_LT = 0xb
AArch64CC_GT = 0xc
AArch64CC_LE = 0xd
AArch64CC_AL = 0xe
AArch64CC_NV = 0xf
AArch64CC_Invalid = 16

[a2 13 00 54] "b.hs #0x3e408" -> cs_insn.cc: 3 ; should be 2
[01 96 00 54] "b.ne #0x3fe0c" -> cs_insn.cc: 2 ; should be 1
[8a 00 00 54] "b.ge #0x41c9c" -> cs_insn.cc: 11; should be 10

Additional Logs, screenshots, source code, configuration dump, ...

Drag and drop zip archives containing the Additional info here, don't use external services or link.
Screenshots can be directly dropped here.

[jiegec]

Reproduced on v5 branch:

$ ./cstool -d arm64 00980354
 0  00 98 03 54  b.eq   #0x7300
        ID: 47 (b)
        op_count: 1
                operands[0].type: IMM = 0x7300
                operands[0].access: READ
        Code-condition: 1
        Registers read: nzcv
        Groups: jump branch_relative

Fixed on next branch:

$ ./cstool -d aarch64 00980354
 0  00 98 03 54  b.eq   0x7300
        ID: 51 (b)
        op_count: 1
                operands[0].type: IMM = 0x7300
                operands[0].access: READ
        Code-condition: 0
        Registers read: nzcv
        Groups: jump branch_relative

[poisonflood]

@jiegec thanks

[Rot127]

The CC enum changed from v5 to v6. This is where the mismatch is coming from.
This is mentioned in the release guide: https://github.com/capstone-engine/capstone/blob/next/docs/cs_v6_release_guide.md (See change table from AArch64 and ARM).

There are two reasons for this:

1. The enumeration values match the actual CC encodings from the ISA. One aim of v6 was to be as close to the ISA as possible and be directly comparable to LLVM. Making this change removes one inconsistency between Capstone and LLVM/ISA.
2. It is easier to generate the code. Because we don't need to patch LLVM code which assumes CC_EQ == 0.