[ARMv7] Decode VFP vmov (register) instead of vmov (immediate)

[eastagiletracker]

This PR proposes decoding the ARMv7 VFP vmov (register) form as a register move instead of a floating-point immediate move, which fixes #3986. We include this PR work along with a full history of your repo at https://eastagiletracker.com/projects/746. You can sign in with your GitHub ID to claim ownership of the project.

In the VFP data-processing space (opc1 = 1x11, opc2 = 0000), opc3 = 01 is VMOV (register) and opc3 = 11 is VABS; VMOV (immediate) is only the opc3 = x0 slot. armv7_floating_point_data_processing sent opc3 = 01 down an immediate path, reading Vn:Vm as an 8-bit float immediate and producing a D register for f32 (a Q register for f64). The fix gives opc3 = 01 the same S/D register operands the VABS branch already uses and only switches the operation. Because the lifter's generic REG, REG case of ARMV7_VMOV now receives real registers, the instruction also lifts to a register copy instead of writing a constant into an unrelated register.

Reproduction on current dev (84d2a2d), using the harness in arch/armv7/armv7_disasm/test.c (gcc -g test.c armv7.c -o test):

$ ./test eef00a41     # expected: vmov.f32 s1, s2
00000000: vmov.f32	d1, #2.125000
$ ./test eeb00b41     # expected: vmov.f64 d0, d1
00000000: vmov.f64	q0, #2.125000e+00
$ ./test 0eb00a41     # expected: vmoveq.f32 s0, s2
00000000: vmoveq.f32	d0, #2.125000

With the change these print vmov.f32 s1, s2, vmov.f64 d0, d1 and vmoveq.f32 s0, s2.

Verification: I added five cases to armv7_disasm/test.py (f32, f64, high D registers, and a conditional form). Since test.py stops at its first mismatch, and 137 of its existing cases already fail on dev (branch-target formatting, dmb/dsb options, ldc/stc offsets and similar), I ran every case and compared the failure sets: the five new cases fail on dev and pass with the fix, and the other 137 failures are identical before and after. A sweep of all 262,144 encodings in the 1110 1D11 xxxx Vd 101 sz xxxx xxxx block showed output changing only for the 2,048 VMOV (register) encodings (opc2 = 0000, opc3 = 01, bit 4 clear), and all 2,048 now match Capstone 5 exactly. VABS and VMOV (immediate) output is unchanged.

test_lift.py had one case built on the old decoding (ee b0 0a 60, commented vmov.f32 d0, #2.000000, expecting LLIL_SET_REG.q(d0,LLIL_CONST.q(0x40000000))). That encoding is vmov.f32 s0, s1, so I changed its expectation to LLIL_SET_REG.d(s0,LLIL_REG.d(s1)), in the same form as the existing vsel lift cases. That script needs a licensed core, so I could not run it here and worked out the expected string from the lifter source; it is worth a run on your side. I also saw the issue is assigned, so feel free to close this if a fix is already underway.

How this was managed

This work was tracked as a story on a board imported from this repository's issues and pull requests (8,064 stories): https://eastagiletracker.com/projects/746/stories/773507 on the board at https://eastagiletracker.com/projects/746.

If you'd rather not receive contributions like this, reply no-more-prs on this pull request and we won't open any further ones on your repositories.

---

Lawrence W. Sinclair
CEO / East Agile
linkedin.com/in/lwsinclair/
eastagile.com

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}