Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARM T2 encoding lsl #imm bug #265

Closed
pzread opened this issue Feb 14, 2015 · 3 comments
Closed

ARM T2 encoding lsl #imm bug #265

pzread opened this issue Feb 14, 2015 · 3 comments

Comments

@pzread
Copy link
Contributor

pzread commented Feb 14, 2015

Hi,
Capstone correctly outputs this T2 encoding instruction (thumb mode, detail enabled

ldr.w r3, [r2, r3, lsl #2]

But the <cs_arm_op>.mem.shift.type of the second operand = ARM_SFT_INVALID, which is wrong.

I found that in printT2AddrModeSoRegOperand at arch/ARM/ARMInstPrinter.c

line 2094:    MI->flat_insn->detail->arm.operands[MI->flat_insn->detail->arm.op_count - 1].shift.type = ARM_SFT_LSL;
line 2095:    MI->flat_insn->detail->arm.operands[MI->flat_insn->detail->arm.op_count - 1].shift.value = ShAmt;

It seems like
MI->flat_insn->detail->arm.op_count - 1 should be MI->flat_insn->detail->arm.op_count

@aquynh
Copy link
Collaborator

aquynh commented Feb 14, 2015

On Sat, Feb 14, 2015 at 11:09 PM, PZ Read notifications@github.com wrote:

Hi,
Capstone correct output below T2 encoding intruction (thumb mode

ldr.w r3, [r2, r3, lsl #2]

But the <cs_arm_op>.mem.shift.type of the second operand =
ARM_SFT_INVALID, which is wrong.

I found that in printT2AddrModeSoRegOperand at arch/ARM/ARMInstPrinter.c

line 2094: MI->flat_insn->detail->arm.operands[MI->flat_insn->detail->arm.op_count - 1].shift.type = ARM_SFT_LSL;
line 2095: MI->flat_insn->detail->arm.operands[MI->flat_insn->detail->arm.op_count - 1].shift.value = ShAmt;

It seems like
MI->flat_insn->detail->arm.op_count - 1 should be
MI->flat_insn->detail->arm.op_count

can you provide the input (hexcode) that triggers the problem, so i can
test it?

thanks.

@pzread
Copy link
Contributor Author

pzread commented Feb 14, 2015

sorry, I forget it
here it is
\x52\xF8\x23\x30

@aquynh
Copy link
Collaborator

aquynh commented Feb 15, 2015

this issue was fixed in the next branch with this commit 706b808

this fix will not be ported back to 3.x version because it breaks the API, so please use the next branch (which will released as 4.0 in the future).

thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants