| Summary: | vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM) | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Mark Harris <markh> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | tom |
| Priority: | NOR | ||
| Version: | 3.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 253451 | ||
| Attachments: | Fix for unhandled FCOM instruction | ||
Would it be possible to merge this patch implementing the unhandled FCOM instruction? It's the exact code used for FCOMP except with no fp_pop(). As for the comment which is part of the existing FCOMP code about C1 being set to 0, both the Intel and AMD docs show that FCOM and FCOMP are supposed to set C1 to 0, so if there is a concern there it is not clear what it is. Committed as VEX r3207 with tests in valgrind r15779. |
Created attachment 37961 [details] Fix for unhandled FCOM instruction Attempting to use valgrind on a VHDL simulation compiled to x86_64 code on RHEL 4, I encountered the following message from valgrind: unhandled opc_aux = 0x 2 first_opcode == 0xDC vex amd64->IR: unhandled instruction bytes: 0x49 0xDC 0x96 0xF8 0xFC 0xFF ==30959== valgrind: Unrecognised instruction at address 0xc362215. ==30959== Your program just tried to execute an instruction that Valgrind ==30959== did not recognise. There are two possible reasons for this. ==30959== 1. Your program has a bug and erroneously jumped to a non-code ==30959== location. If you are running Memcheck and you just saw a ==30959== warning about a bad jump, it's probably your program's fault. ==30959== 2. The instruction is legitimate but Valgrind doesn't handle it, ==30959== i.e. it's Valgrind's fault. If you think this is the case or ==30959== you are not sure, please let us know and we'll try to fix it. ==30959== Either way, Valgrind will now raise a SIGILL signal which will ==30959== probably kill your program. This instruction looks legitimate. gdb disassembles it as: 0xc362215: rex.WB fcoml -0x308(%r14) I was able to correct the problem by copying the corresponding VEX code for FCOMP and removing the call to fp_pop(), in VEX/priv/guest_amd64_toIR.c.