MIPS syscall missing int group

[OBarronCS]

Work environment

Questions	Answers
Capstone module affected	mips
Source of Capstone	pip install capstone==6.0.0a4
Version/git commit	6.0.0 alpha 4

Syscalls instructions in MIPS do not include the int group to indicate they are interrupts.

cstool -d mips 0000000c
 0  00 00 00 0c  syscall	
	ID: 1310 (syscall)
	Is alias: 1378 (syscall) with REAL operand set
	Groups: HasStdEnc NotInMicroMips NotNanoMips 

cstool -d mips64 0000000c
 0  00 00 00 0c  syscall	
	ID: 1310 (syscall)
	Is alias: 1378 (syscall) with REAL operand set
	Groups: HasStdEnc NotInMicroMips NotNanoMips 

Expected behavior

Expected that the int group is present. It is present in v5.0.6.

Steps to reproduce the behavior

cstool -d mips 0000000c
cstool -d mips64 0000000c

[wargio]

seems that the group int is set, but is not there somehow.

[wargio]

https://github.com/capstone-engine/capstone/blob/next/arch/Mips/MipsMappingInsn.inc#L8815

[Rot127]

This is the old unused file. It shouldn't be there actually. This is the one in question: https://github.com/capstone-engine/capstone/blob/895f2f2e10c245a45880c07c2666d498e62d8ecf/arch/Mips/MipsGenCSMappingInsn.inc#L23384-L23388

@OBarronCS The change is LLVM related. LLVM doesn't define interrupts as such. The INT flag was added by Capstone, because back then it was all hand-written semi-generated. With the Auto-Sync updater these files are fully generated and the custom Capstone flags are only added later if necessary.

For Mips they were not added yet. But we should overthink the whole thing. Mips instructions define a isCTI flag (here). With isCTI it marks the instruction as Control Transfer Instruction. We should rather add this flag if the bit is set instead of the "interrupt" flag.