Bug 228072 - vex amd64->IR: unhandled instruction bytes: 0x66 0x45 0xF 0x38 0x30 0xD2
Summary: vex amd64->IR: unhandled instruction bytes: 0x66 0x45 0xF 0x38 0x30 0xD2
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (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: 2010-02-22 16:17 UTC by Sam Jansen
Modified: 2011-08-12 16:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Sam Jansen 2010-02-22 16:17:39 UTC
We receive an "unhandled instruction bytes" error running valgrind on our
codebase on Ubuntu Linux 9.04 x86_64, using valgrind 3.5.0 compiled from
sources. This appears to be due to use of SSE instructions (we use gcc inline
assembler / intrinsics to make use of SSE instructions).

It appears to be due to the following code (valgrind reports this line as an error):

  #define load_v8hi(reg, loc)                     \
      asm("movq %1,%0     \n"                     \
          "pmovzxbw %0,%0 \n"                     \
          : "=x"(reg)                             \
          : "m"(*(v8hi*)(loc)))

      load_v8hi(p2, p_start - 2*pitch);

The opcode valgrind errors on corresponds to the PMOVZXBW instruction used
in our code above.

We found this on version 3.5.0, but have also tried an SVN checkout as of
2010-02-22 15:10 GMT with the same error.

Transcript of this error follows:

$ valgrind --version

valgrind --error-exitcode=1 --quiet --suppressions=base/test/valgrind_suppressions.sup --malloc-fill=CD --free-fill=FE --leak-check=full build/x86_64/release/... (our executable here)
vex amd64->IR: unhandled instruction bytes: 0x66 0x45 0xF 0x38 0x30 0xD2
==13677== valgrind: Unrecognised instruction at address 0x438c85.
==13677== Your program just tried to execute an instruction that Valgrind
==13677== did not recognise.  There are two possible reasons for this.
==13677== 1. Your program has a bug and erroneously jumped to a non-code
==13677==    location.  If you are running Memcheck and you just saw a
==13677==    warning about a bad jump, it's probably your program's fault.
==13677== 2. The instruction is legitimate but Valgrind doesn't handle it,
==13677==    i.e. it's Valgrind's fault.  If you think this is the case or
==13677==    you are not sure, please let us know and we'll try to fix it.
==13677== Either way, Valgrind will now raise a SIGILL signal which will
==13677== probably kill your program.
==13677== Process terminating with default action of signal 4 (SIGILL)
Comment 1 Tom Hughes 2011-08-12 16:20:26 UTC
This instruction was added in VEX r1965.