|
From: Alexander P. <gl...@go...> - 2010-01-28 15:58:38
|
Hi all,
Debugging some test under Valgrind on ARM I've noticed that VEX
handles some vmov instructions incorrectly on that platform.
In particular, VMOV dM, rD, rN handler relies on the fact that (opcode
& 0x0ff00ff0) == 0x0c400b10 (see VEX/priv/guest_arm_toIR.c)
This is ok for dM in the range from d0 to d15, but for d16..d31 it is
just incorrect:
8410: ec400b30 vmov d16, r0, r0
8414: ec400b31 vmov d17, r0, r0
8418: ec400b32 vmov d18, r0, r0
841c: ec400b33 vmov d19, r0, r0
8420: ec400b34 vmov d20, r0, r0
8424: ec400b35 vmov d21, r0, r0
8428: ec400b36 vmov d22, r0, r0
842c: ec400b37 vmov d23, r0, r0
8430: ec400b38 vmov d24, r0, r0
8434: ec400b38 vmov d24, r0, r0
8438: ec400b39 vmov d25, r0, r0
843c: ec400b3a vmov d26, r0, r0
8440: ec400b3b vmov d27, r0, r0
8444: ec400b3c vmov d28, r0, r0
8448: ec400b3d vmov d29, r0, r0
844c: ec400b3e vmov d30, r0, r0
8450: ec400b3f vmov d31, r0, r0
(a piece of objdump -d output)
After fixing this locally I've bumped into several assertions that
relied on the fact the Dreg number is less than 16.
I am sure I can just copy and paste code to double the number of
D-registers in VEX, but won't it break anything?
Thanks,
Alexander Potapenko
Software Engineer
Google Moscow
|