Bug 212352

Summary: vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM)
Product: [Developer tools] valgrind Reporter: Mark Harris <markh>
Component: vexAssignee: 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

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.