Bug 509899

SUMMARY

I am writing a 64-bit program using some obscure x87 FPU instructions to help me load and store binary-coded decimal numbers. Although most of Intel's BCD instructions are 32-bit only, the x87-specific FBSTP (Store BCD integer and pop) instruction still exists in 64-bit mode. When I execute this instruction without valgrind, everything works as intended. However, when running valgrind, it crashes, giving an illegal opcode signal.

STEPS TO REPRODUCE

1. Assemble and link an assembly file that makes use of the FBSTP instruction.
2. Run valgrind on the program the assembly functions are linked to.

OBSERVED RESULT

Valgrind crashes.

EXPECTED RESULT

Valgrind does not crash.

SOFTWARE/OS VERSIONS
uname output:
Linux andre-elementary 6.14.0-29-generic #29~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Aug 14 16:52:50 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

ADDITIONAL INFORMATION

Here's the output to the console as valgrind crashes. Notice how the unhandled exception bytes begin with 0xDF, which matches with the opcode of the FBSTP instruction ( DF, /6 ):

unhandled opc_aux = 0x 6
first_opcode == 0xDF
vex amd64->IR: unhandled instruction bytes: 0xDF 0x37 0xC3 0x48 0x83 0xEC 0x10 0xF3 0xF 0x7F
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==70917== valgrind: Unrecognised instruction at address 0x2676c6.
==70917==    at 0x2676C6: ??? (in /home/andre/eclipse-workspace/sunmoon/Debug/sunmoon)
==70917==    by 0x4C341C9: (below main) (libc_start_call_main.h:58)
==70917== Your program just tried to execute an instruction that Valgrind
==70917== did not recognise.  There are two possible reasons for this.
==70917== 1. Your program has a bug and erroneously jumped to a non-code
==70917==    location.  If you are running Memcheck and you just saw a
==70917==    warning about a bad jump, it's probably your program's fault.
==70917== 2. The instruction is legitimate but Valgrind doesn't handle it,
==70917==    i.e. it's Valgrind's fault.  If you think this is the case or
==70917==    you are not sure, please let us know and we'll try to fix it.
==70917== Either way, Valgrind will now raise a SIGILL signal which will
==70917== probably kill your program.
==70917== 
==70917== Process terminating with default action of signal 4 (SIGILL)
==70917==  Illegal opcode at address 0x2676C6
==70917==    at 0x2676C6: ??? (in /home/andre/eclipse-workspace/sunmoon/Debug/sunmoon)
==70917==    by 0x4C341C9: (below main) (libc_start_call_main.h:58)
==70917== 
==70917== HEAP SUMMARY:
==70917==     in use at exit: 23,724,470 bytes in 97,022 blocks
==70917==   total heap usage: 115,227 allocs, 18,205 frees, 32,392,203 bytes allocated
==70917== 
==70917== Searching for pointers to 97,022 not-freed blocks
==70917== Checked 274,526,968 bytes
==70917== 
==70917== LEAK SUMMARY:
==70917==    definitely lost: 0 bytes in 0 blocks
==70917==    indirectly lost: 0 bytes in 0 blocks
==70917==      possibly lost: 8,945,293 bytes in 63,616 blocks
==70917==    still reachable: 14,779,177 bytes in 33,406 blocks
==70917==                       of which reachable via heuristic:
==70917==                         newarray           : 839,112 bytes in 9 blocks
==70917==                         multipleinheritance: 960 bytes in 8 blocks
==70917==         suppressed: 0 bytes in 0 blocks
==70917== Rerun with --leak-check=full to see details of leaked memory
==70917== 
==70917== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction (core dumped)