I am getting a strange error with valgrind on a program that makes use of Crypto++’s zlib functions:
vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
==8605== valgrind: Unrecognised instruction at address 0x814c88b.
==8605== at 0x814C88B: CryptoPP::ByteQueue::TransferTo2(CryptoPP::BufferedTransformation&, unsigned long long&, std::string const&, bool) (misc.h:189)
==8605== by 0x814C3E6: CryptoPP::ByteQueue::Get(unsigned char*, unsigned int) (cryptlib.h:901)
==8605== by 0x815DAAE: CryptoPP::ZlibDecompressor::ProcessPoststreamTail() (zlib.cpp:84)
==8605== by 0x815B6EC: CryptoPP::Inflator::ProcessInput(bool) (zinflate.cpp:349)
==8605== by 0x815BC25: CryptoPP::Inflator::Put2(unsigned char const*, unsigned int, int, bool) (zinflate.cpp:295)
==8605== by 0x805E40C: CryptoPP::BufferedTransformation::Put(unsigned char const*, unsigned int, bool) (cryptlib.h:789)
I know that Crypto++ uses some hand-coded assembly in certain areas to speed things up, and I’ve read that instructions starting with 0xC5 are never present in compiled code. Could this be due to an assembly instruction from a piece of hand-coded assembly? And if so, can I disable this check by valgrind so that I can continue to test my program?
This is an AVX instruction. Valgrind does not currently support AVX instructions, but AVX support is under development. Because valgrind works by emulating each instruction, it is not just a check that you can bypass unless you want it to jump directly to the actual instruction, which would disable valgrind altogether for the remainder of the execution.