Capstone's instruction classification is weak for ARM

[pfalcon]

ldm aka pop instruction for ARM affecting pc register should be classified as CS_GRP_RET, because, well, it's a control transfer instruction, usually used to implement (optimize) return from a subroutine.

Without cases like that, Capstone's instruction classification isn't much useful, and needs to be worked around in adhoc way on app's side. For example, for a recursive traversal disassembler, properly classified instruction are of utmost importance. If return insns are misclassified, a disassembler may disassemble what is not instructions.

[pfalcon]

Another problem: bl (at least in Thumb mode) is classified only as ARM_GRP_THUMB, but it is CS_GRP_CALL.

[maximumspatium]

+1

For PowerPC, it's even much worse! It looks like there was just a single semantic group in this arch: PPC_GRP_JUMP.
Serious? What's about PPC_GRP_CALL, PPC_GRP_RET?

The lack of the proper instruction classification in Capstone makes this otherwise great library unsuitable for semi-automatic static program analysis. Tools like recursive disassemblers or decompilers usually operate on basic blocks. In order to be able to analyze the control flow of a program, it's not enough to know whether an instruction is a branch or not; it could be an unconditional branch (one-way control flow), a conditional branch (two-way control flow), a call, a return or even an indirect branch.

The problem is that such a functionality has to be added or worked around in every project that requires it, worse yet, in a non-portable manner. I did it earlier and I know that some other people do it, too.

I therefore propose

• to augment the Capstone library with a richer set of instruction semantic classes than currently exists. This implies that the branch group need a more precise specification than simply JUMP. It should be possible to differentiate between conditional, unconditional, indirect branches as well as CALL and RET.
• fix the existing Capstone disassemblers to report instruction semantics in a consistent way. In other words, no more "fixes" in the user code.

I'd assist on PowerPC and 68k. But the desired API consistency need to be provided by library maintainer(s).