Bug 369264 - Fedora 24 i686 and vex x86->IR: unhandled instruction bytes: 0xC5 0xF8 0x10 0x3
Summary: Fedora 24 i686 and vex x86->IR: unhandled instruction bytes: 0xC5 0xF8 0x10 0x3
Status: RESOLVED INTENTIONAL
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.12 SVN
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-23 23:54 UTC by Jeffrey Walton
Modified: 2016-10-19 14:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Walton 2016-09-23 23:54:00 UTC
I'm working from Fedora 24 i686 fully patched. I also built Valgrind from SVN sources. Finally, I'm running Wei Dai's Crypto++ program under Valgrind.

My apologies if this has been reported. Searching for "All" bugs under product "Valgrind" for the string "0xC5 0xF8 0x10 0x3" returned 0 hits.

$ g++ --version
g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
Copyright (C) 2015 Free Software Foundation, Inc.

$ /usr/local/bin/valgrind ./cryptest.exe v
==9138== Memcheck, a memory error detector
==9138== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9138== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==9138== Command: ./cryptest.exe v
==9138== 
Using seed: 1474674382      
...

MD2 validation suite running...

vex x86->IR: unhandled instruction bytes: 0xC5 0xF8 0x10 0x3
==9138== valgrind: Unrecognised instruction at address 0x821642c.
==9138==    at 0x821642C: CryptoPP::Weak1::MD2::Update(unsigned char const*, unsigned int) (md2.cpp:74)
==9138==    by 0x82167A1: CryptoPP::Weak1::MD2::TruncatedFinal(unsigned char*, unsigned int) (md2.cpp:112)
==9138==    by 0x805699F: CryptoPP::HashTransformation::Final(unsigned char*) (cryptlib.h:964)
==9138==    by 0x8101246: HashModuleTest(CryptoPP::HashTransformation&, HashTestTuple const*, unsigned int) (validat3.cpp:82)
==9138==    by 0x8101963: ValidateMD2() (validat3.cpp:173)
==9138==    by 0x80B255F: ValidateAll(bool) (validat1.cpp:97)
==9138==    by 0x80551F1: Validate(int, bool, char const*) (test.cpp:894)
==9138==    by 0x804F57D: main (test.cpp:360)
==9138== Your program just tried to execute an instruction that Valgrind
==9138== did not recognise.  There are two possible reasons for this.
==9138== 1. Your program has a bug and erroneously jumped to a non-code
==9138==    location.  If you are running Memcheck and you just saw a
==9138==    warning about a bad jump, it's probably your program's fault.
==9138== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9138==    i.e. it's Valgrind's fault.  If you think this is the case or
==9138==    you are not sure, please let us know and we'll try to fix it.
==9138== Either way, Valgrind will now raise a SIGILL signal which will
==9138== probably kill your program.
==9138== 
==9138== Process terminating with default action of signal 4 (SIGILL)
==9138==  Illegal opcode at address 0x821642C
==9138==    at 0x821642C: CryptoPP::Weak1::MD2::Update(unsigned char const*, unsigned int) (md2.cpp:74)
==9138==    by 0x82167A1: CryptoPP::Weak1::MD2::TruncatedFinal(unsigned char*, unsigned int) (md2.cpp:112)
==9138==    by 0x805699F: CryptoPP::HashTransformation::Final(unsigned char*) (cryptlib.h:964)
==9138==    by 0x8101246: HashModuleTest(CryptoPP::HashTransformation&, HashTestTuple const*, unsigned int) (validat3.cpp:82)
==9138==    by 0x8101963: ValidateMD2() (validat3.cpp:173)
==9138==    by 0x80B255F: ValidateAll(bool) (validat1.cpp:97)
==9138==    by 0x80551F1: Validate(int, bool, char const*) (test.cpp:894)
==9138==    by 0x804F57D: main (test.cpp:360)
Comment 1 Mark Wielaard 2016-09-24 07:57:53 UTC
That is vmovups which is only supported by valgrind as amd64 (x86_64) instruction.
Comment 2 Julian Seward 2016-10-19 14:51:23 UTC
On 32-bit x86, only SSSE3 and below are supported.