FinnWilkinson
commented
8 months ago Looking into this a bit further, it seems to originate from the AArch64GenCSMappingInsnOp.inc file where all SME based instructions with an index have CS_OP_MEM.
In capstone's LLVM, llvm/utils/TableGen/PrinterCapstone.cpp the function getCSOperandType contains
if (TargetName.equals("AArch64") && OperandType != "CS_OP_MEM") {
// The definitions of AArch64 are so broken, when it comes to memory
// operands, that we just search for the op name enclosed in [].
if (Regex("\\[.*\\$" + OpName.str() + ".*]").match(CGI->AsmString))
return OperandType += " | CS_OP_MEM";
}Which would explain the above issues with LD1W and ST1W whereby p2 is seen as a memory operand (The open bracket [ is part of za0h's index, the close bracket ] is part of the actual memory operand
I think it also explains the issue with PSEL as all predicate registers are recognised correctly but p3's index is seen as a memory operand rather than its index.
Looking at other SME instructions in AArch64GenCSMappingInsnOp.inc, instruction opcode AArch64_ADD_VG2_M2Z2Z_D could potentially present a similar issue to PSEL where ZA's index is seen as a memory operand rather than an index --- again this could be explained by the above regex
{ /* AArch64_ADD_VG2_M2Z2Z_D (1265) - AArch64_INS_ADD - add $ZAd[$Rv, $imm3, vgx2], $Zn, $Zm */
{
{ CS_OP_REG, CS_AC_WRITE, { CS_DATA_TYPE_Untyped, CS_DATA_TYPE_LAST } }, /* ZAd */
{ CS_OP_REG, CS_AC_READ, { CS_DATA_TYPE_Untyped, CS_DATA_TYPE_LAST } }, /* _ZAd */
{ CS_OP_REG | CS_OP_MEM, CS_AC_INVALID, { CS_DATA_TYPE_i32, CS_DATA_TYPE_LAST } }, /* Rv */
{ CS_OP_IMM | CS_OP_MEM, CS_AC_INVALID, { CS_DATA_TYPE_i32, CS_DATA_TYPE_LAST } }, /* imm3 */
{ CS_OP_REG, CS_AC_READ, { CS_DATA_TYPE_Untyped, CS_DATA_TYPE_LAST } }, /* Zn */
{ CS_OP_REG, CS_AC_READ, { CS_DATA_TYPE_Untyped, CS_DATA_TYPE_LAST } }, /* Zm */
{ 0 }
}},
Rot127
Working on the latest
nextbranch, disassembling a range of SME instructions yields incorrect disassembly information, often with additional memory operands being defined.It seems to be an issue with the pattern matching of
[...]. A similar issue occurred when implementing PR #1907 and was fixed in PR #1925. I'm not sure how different the backend is now after the auto-sync update, but perhaps a similar fix can be implemented from this?Listed below are some examples:
Issue - Operand 2
p3.s's index is identified as an additional memory operand.Issue - Operand
p4is mistaken for a memory operand andx10as its register offset. Also, operands[0] should not have an access specifier, and operands[2] should not have a vector indexIssue - Same as above.