Multiple issues with arm64 integer SIMD instructions
- Dominant language
- C++
- Stars
- 8.6k
- Forks
- 1k
- PR merge metrics
- No merged PRs in 30d
Description
The subject at https://github.com/rfalke/decompiler-subjects/tree/master/from_holdec/stress_arm64/arm64_macho_simdInt_single_inst__1_var is designed that each function tests one instruction variant. The test is successful if the decompiled version writes three times a zero to global variables.
In the following example `10002a1d0: 2d 1c a1 0e mov.8b v13, v1` is tested.
objdump:
```
000000010002a180 <_inst_680_var_0>:
10002a180: 60 72 9a d2 mov x0, #54163
10002a184: 40 2f ae f2 movk x0, #29050, lsl #16
10002a188: e0 8b de f2 movk x0, #62559, lsl #32
10002a18c: e0 a1 f4 f2 movk x0, #42255, lsl #48
10002a190: 01 00 67 9e fmov d1, x0
10002a194: a0 97 9f d2 mov x0, #64701
10002a198: c0 f6 b9 f2 movk x0, #53174, lsl #16
10002a19c: 20 d7 c0 f2 movk x0, #1721, lsl #32
10002a1a0: c0 ff f3 f2 movk x0, #40958, lsl #48
10002a1a4: 01 00 af 9e fmov.d v1[1], x0
10002a1a8: 00 b7 9d d2 mov x0, #60856
10002a1ac: 60 9d a2 f2 movk x0, #5355, lsl #16
10002a1b0: a0 66 c0 f2 movk x0, #821, lsl #32
10002a1b4: 40 6c ff f2 movk x0, #64354, lsl #48
10002a1b8: 0d 00 67 9e fmov d13, x0
10002a1bc: 40 1d 90 d2 mov x0, #33002
10002a1c0: 40 1c a0 f2 movk x0, #226, lsl #16
10002a1c4: c0 2a c4 f2 movk x0, #8534, lsl #32
10002a1c8: a0 96 ec f2 movk x0, #25781, lsl #48
10002a1cc: 0d 00 af 9e fmov.d v13[1], x0
10002a1d0: 2d 1c a1 0e mov.8b v13, v1
10002a1d4: 21 1c 2d 6e eor.16b v1, v1, v13
10002a1d8: 20 00 ae 9e fmov.d x0, v1[1]
10002a1dc: 21 00 66 9e fmov x1, d1
10002a1e0: e4 03 1f aa mov x4, xzr
10002a1e4: a2 97 9f d2 mov x2, #64701
10002a1e8: c2 f6 b9 f2 movk x2, #53174, lsl #16
10002a1ec: 22 d7 c0 f2 movk x2, #1721, lsl #32
10002a1f0: c2 ff f3 f2 movk x2, #40958, lsl #48
10002a1f4: 00 00 02 cb sub x0, x0, x2
10002a1f8: 02 00 80 d2 mov x2, #0
10002a1fc: 02 00 a0 f2 movk x2, #0, lsl #16
10002a200: 02 00 c0 f2 movk x2, #0, lsl #32
10002a204: 02 00 e0 f2 movk x2, #0, lsl #48
10002a208: 21 00 02 cb sub x1, x1, x2
10002a20c: a2 00 00 d0 adrp x2, #90112
10002a210: 42 80 00 91 add x2, x2, #32
10002a214: 40 00 00 f9 str x0, [x2]
10002a218: a2 00 00 d0 adrp x2, #90112
10002a21c: 42 a0 00 91 add x2, x2, #40
10002a220: 41 00 00 f9 str x1, [x2]
10002a224: a2 00 00 d0 adrp x2, #90112
10002a228: 42 60 00 91 add x2, x2, #24
10002a22c: 44 00 00 f9 str x4, [x2]
10002a230: e0 03 1f 2a mov w0, wzr
10002a234: c0 03 5f d6 ret
```
retdec-output:
```
// Address range: 0x10002a180 - 0x10002a238
int64_t _inst_680_var_0(void) {
// 0x10002a180
__asm_fmov(-0x6001f94630490343);
__asm_fmov(0x64b5215600e280ea);
int64_t v1 = __asm_fmov_4(0.0); // 0x10002a1d8
*(int64_t *)((int64_t)&g1 + 32) = v1 + 0x6001f94630490343;
*(int64_t *)((int64_t)&g1 + 40) = -0x5af00ba08e852c6d;
*(int64_t *)((int64_t)&g1 + 24) = 0;
return 0;
}
```
Issues:
- `*(int64_t *)((int64_t)&g1 + 32)` and co should be replaced with `_dest_high` and co
- in roughly all functions occurs `__asm_fmov_4(0.0)` with zero as parameter
- No idea what the `4` stands for.
- It is possible that `__asm_fmov_4(0.0)` is `0`?
- Either the values of the `__asm_fmov` calls are used or they are not used but then the call should be removed since they have no other side effect.
- the first 2 writes should similar to the last one have a zero at the RHS.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the arm64_macho_simdInt_single_inst__1_var subject and compare the objdump listing with the retdec-output for the shown instruction. Check the output for the listed destination names, fmov calls, and three global writes; done means the reported SIMD cases produce the expected zero values without the described spurious output.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers, reverse-engineering
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100