capstone-engine
Invalid ID for riscv64 RET instruction
$ ./cstool/cstool -d riscv64 67800000
0 67 80 00 00 ret
ID: 207 (jalr)
i have started to add the riscv support to r2 by using Capstone (we have been using our own analysis and the gnu disassembler until now), so i'll be adding more issues when i compare results and improve the plugin outputs.
@fanfuqiang @citypw i think the mapping for RET is wrong in https://github.com/aquynh/capstone/blob/next/arch/RISCV/RISCVMappingInsn.inc?
I looked at the mapping file, and think the bug is elsewhere. Is RET just an alias? If so, you may forget to map alias mnemonic back to alias ID, which explains why we still see the original instruction ID.
I looked at the mapping file, and think the bug is elsewhere. Is RET just an alias? If so, you may forget to map alias mnemonic back to alias ID, which explains why we still see the original instruction ID.
Thx, I am fixing.
Specification of riscv has:
Pseudoinstruction: ret equals
Base Instructions: jalr x0, x1, 0; auipc x6, offset[31:12] for legibility.
so as ret is not a real Instruction in chip.
I had dig into the code. looks like it is an upstream bug. when LLVM meet jalr x0, x1, 0 immediately return "ret".
Of course, this happens when enabling alias instructions.
I am working on this.
@radare @aquynh Sorry, guys, my mistake.
Actually, ret only ALIAS jalr x0, x1, 0.
The bad typesetting of RISCV specification makes me blind.
For now, I use an easy way to fix this.
I just disable alias instruction display when Capstone enables details.
CASE A:
./cstool -d riscv64 67800000
0 67 80 00 00 jalr zero, ra, 0
ID: 207 (jalr)
op_count: 3
operands[0].type: REG = zero
operands[1].type: REG = ra
operands[2].type: IMM = 0x0
So what do you want? enable alias instruction display like this?
CASE B:
./cstool -d riscv64 67800000
0 67 80 00 00 ret
ID: 207 (jalr)
op_count: 3
operands[0].type: REG = zero
operands[1].type: REG = ra
operands[2].type: IMM = 0x0
or previous?