Work environment
| Questions |
Answers |
| System Capstone runs on OS/arch/bits |
Windows x86_64 |
| Capstone module affected |
aarch64 |
| Source of Capstone |
git clone |
| Version/git commit |
6.0.0-Alpha9 |
Instruction bytes giving faulty results
Expected results
It should be:
sel { z0.b, z1.b }, pn10, { z8.b, z9.b }, { z16.b, z17.b }
But it actually gives:
sel { z0.b, z1.b }, pn0xa, { z8.b, z9.b }, { z16.b, z17.b }
pn0–pn9 print correctly; pn10–pn15 are wrongly printed in hex (pn0xa–pn0xf).
Steps to get the wrong result
With cstool:
cstool.exe -d aarch64 "0x00,0x89,0x30,0xc1" 0x1000
Additional Logs, screenshots, source cod
Root cause: in printPredicateAsCounter (arch/AArch64/AArch64InstPrinter.c), the register number is emitted with printUInt32:
printUInt32(O, (Reg - AArch64_PN0));
printUInt32 switches to 0x%x for values above HEX_THRESHOLD (= 9, utils.h). That threshold is meant for immediates, but here the value is a registerecimal.
Suggested fix:
SStream_concat(O, "%u", (Reg - AArch64_PN0));
Work environment
git cloneInstruction bytes giving faulty results
Expected results
It should be:
But it actually gives:
pn0–pn9print correctly;pn10–pn15are wrongly printed in hex (pn0xa–pn0xf).Steps to get the wrong result
With
cstool:Additional Logs, screenshots, source cod
Root cause: in
printPredicateAsCounter(arch/AArch64/AArch64InstPrinter.c), the register number is emitted withprintUInt32:printUInt32switches to0x%xfor values aboveHEX_THRESHOLD(= 9,utils.h). That threshold is meant for immediates, but here the value is a registerecimal.Suggested fix: