Bug 212352 - vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM)
Summary: vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM)
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.5.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
Depends on:
Blocks: 253451
  Show dependency treegraph
Reported: 2009-10-30 05:10 UTC by Mark Harris
Modified: 2016-02-03 10:16 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:

Fix for unhandled FCOM instruction (1.55 KB, patch)
2009-10-30 05:10 UTC, Mark Harris

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Harris 2009-10-30 05:10:35 UTC
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.
Comment 1 Mark Harris 2016-01-22 04:35:05 UTC
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.
Comment 2 Tom Hughes 2016-02-03 10:16:21 UTC
Committed as VEX r3207 with tests in valgrind r15779.