capstone icon indicating copy to clipboard operation
capstone copied to clipboard

LDRSW: AARCH64 don't have correct access

Open poisonflood opened this issue 2 months ago • 1 comments

Work environment

Questions Answers
System Capstone runs on OS/arch/bits , Arch x86-64
Capstone module affected aarch64
Source of Capstone git clone
Version/git commit edb1ac731b3d4de1e5879c70957a8bf2fe0b7bd0

Instruction bytes giving faulty results

CA 7A AA B8

the bug in my log:

 3663         operands[1].type: MEM
 3664             - operands[1].mem.base: REG = x22 (0xA7D0)
 3665             - operands[1].mem.index: REG = x10 (0x2)
 3666             Shift: LSL #2
 3667             → effective address: 0xA7D8
 3668             → direction: 0x0
 3669             → cs_insn.writeback: 0b0
 3670             - operands[1].access: 0 CS_AC_WRITE: 2 CS_AC_READ: 1
 3671 [0x00002BDC] [CA 7A AA B8] 0x00002BD8: "LDRSW X10, [X22, X10, LSL #2]" X22=0xA7D0 X10=0x2 => X10=0xFFFFFFFFFFFF8970

Expected results

It should be:

 3670             - operands[1].access: 1 CS_AC_WRITE: 2 CS_AC_READ: 1
                                                             ---

Steps to get the wrong result

With cstool:

./cstool -d aarch64 "CA 7A AA B8"
 0  ca 7a aa b8  ldrsw  x10, [x22, x10, lsl #2]
        ID: 638 (ldrsw)
        op_count: 2
                operands[0].type: REG = x10
                operands[0].access: WRITE
                operands[1].type: MEM
                        operands[1].mem.base: REG = x22
                        operands[1].mem.index: REG = x10
                        Shift: type = 1, value = 2
        Registers read: x22 x10
        Registers modified: x10

poisonflood avatar Oct 19 '25 10:10 poisonflood

Cause:

The access information is not generated correctly:

AArch64GenCSMappingInsnOp.inc:

{ /* AARCH64_LDRSWroW (4503) - AARCH64_INS_LDRSW - ldrsw	$Rt, [$Rn, $Rm, $extend] */
{
  { CS_OP_REG, CS_AC_WRITE, { CS_DATA_TYPE_i64, CS_DATA_TYPE_LAST } }, /* Rt */
  { CS_OP_REG | CS_OP_MEM, CS_AC_INVALID, { CS_DATA_TYPE_i64, CS_DATA_TYPE_LAST } }, /* Rn */
  { CS_OP_REG | CS_OP_MEM, CS_AC_INVALID, { CS_DATA_TYPE_i32, CS_DATA_TYPE_LAST } }, /* Rm */
  { CS_OP_MEM | CS_OP_IMM, CS_AC_INVALID, { CS_DATA_TYPE_i32, CS_DATA_TYPE_LAST } }, /* extend - i32imm */
  { CS_OP_MEM | CS_OP_IMM, CS_AC_INVALID, { CS_DATA_TYPE_i32, CS_DATA_TYPE_LAST } }, /* extend - i32imm */
  { 0 }
}},
{ /* AARCH64_LDRSWroX (4504) - AARCH64_INS_LDRSW - ldrsw	$Rt, [$Rn, $Rm, $extend] */
{
  { CS_OP_REG, CS_AC_WRITE, { CS_DATA_TYPE_i64, CS_DATA_TYPE_LAST } }, /* Rt */
  { CS_OP_REG | CS_OP_MEM, CS_AC_INVALID, { CS_DATA_TYPE_i64, CS_DATA_TYPE_LAST } }, /* Rn */
  { CS_OP_REG | CS_OP_MEM, CS_AC_INVALID, { CS_DATA_TYPE_i64, CS_DATA_TYPE_LAST } }, /* Rm */
  { CS_OP_MEM | CS_OP_IMM, CS_AC_INVALID, { CS_DATA_TYPE_i32, CS_DATA_TYPE_LAST } }, /* extend - i32imm */
  { CS_OP_MEM | CS_OP_IMM, CS_AC_INVALID, { CS_DATA_TYPE_i32, CS_DATA_TYPE_LAST } }, /* extend - i32imm */
  { 0 }
}},

We can fix this after https://github.com/capstone-engine/llvm-capstone/pull/83 was merged. It should make the access type generation more precise because it depends on mayLoad and mayStore flags.

Rot127 avatar Oct 19 '25 14:10 Rot127