https://bugs.kde.org/show_bug.cgi?id=509899
Bug ID: 509899
Summary: Illegal Opcode crash when executing x87 BCD
instructions
Classification: Developer tools
Product: valgrind
Version First 3.22.0
Reported In:
Platform: Other
OS: Unspecified
Status: REPORTED
Severity: crash
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
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)
--
You are receiving this mail because:
You are watching all bug changes.
