Bug 475402

Summary: vex amd64->IR: unhandled instruction bytes: 0xC5 0x79 0xD6 0xC0 0x4C 0x8D 0x9C 0x24 0xA0 0x2
Product: [Developer tools] valgrind Reporter: Julien Jorge <julien.jorge>
Component: memcheckAssignee: Julian Seward <jseward>
Status: RESOLVED FIXED    
Severity: normal CC: pjfloyd, raoulgough, sam
Priority: NOR    
Version First Reported In: 3.22 GIT   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Julien Jorge 2023-10-09 15:10:26 UTC 
When running my program with Valgrind & memcheck, it fails with an unhandled instruction message:

vex amd64->IR: unhandled instruction bytes: 0xC5 0x79 0xD6 0xC0 0x4C 0x8D 0x9C 0x24 0xA0 0x2
vex amd64->IR:   REX=0 REX.W=0 REX.R=1 REX.X=0 REX.B=0
vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==137781== valgrind: Unrecognised instruction at address 0x4cf081.
==137781==    at 0x4CF081: _mm_set_epi64x (emmintrin.h:595)
==137781==    by 0x4CF081: _mm_set_epi64 (emmintrin.h:601)
==137781==    by 0x4CF081: _mm_loadl_epi64 (emmintrin.h:712)

It occurs with Valgrind 3.22 built from source (commit 97508f5561756a43f054c1d8e06c3e318124c9c3) but also with 3.19 from Ubuntu repositories.

The program is compiled using GCC 13.1.0, and executed on the same machine.

Passing -v shows: Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed.
Comment 1 raoulgough 2024-08-20 17:18:23 UTC 
I also encounted this bug and created a simple repro. However, after building from the git head I see that the problem is now fixed. I'm guessing the fix arrived in commit 10a22445d747817932692b1c1ee3faa726121cb4 "Implement VMOVQ xmm1, xmm2/m64". The repro was actually pretty similar to one of the test cases in that commit. For the sake of completeness I've included the repro below, which gives a SIGILL up to and including valgrind 3.23.0. From my testing, it only fails when moving from a register in the xmm8-xmm15 range to the xmm0-xmm7 range. Other combinations (8-15 to 8-15 and 0-7 to 0-15) worked fine.

The bytes in the original report (0xC5 0x79 0xD6 0xC0) correspond to "vmovq  xmm0,xmm8" according to https://defuse.ca/online-x86-assembler.htm which seems to be using Intel argument ordering (DST, SRC) so a move from xmm8 to xmm0.

void foo()
{
    asm volatile(
        "vmovq %%xmm8, %%xmm7"
        :::);
}

int main()
{
    foo();
    return 1;
}
Comment 2 Paul Floyd 2024-08-22 06:09:57 UTC 
I just did a quick test and agree that this is now fixed.