Bug 366344 - Multiple unhandled instruction for Aarch64 (0x0EE0E020, 0x1AC15800, 0x4E284801, 0x5E040023, 0x5E056060)
Summary: Multiple unhandled instruction for Aarch64 (0x0EE0E020, 0x1AC15800, 0x4E28480...
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.11.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-02 11:36 UTC by Jeffrey Walton
Modified: 2016-08-04 23:05 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-08-02 11:36:43 UTC
I'm working on an ODROID C2. Its an ARMv8 device with a Amlogic SoC based on A53 cores. It ships with a 64-bit OS named Linaro, which is Aarch64. The Amlogic SoC has ASIMD (v8 NEON) and CRC32, but it lacks Crypto extensions.

The flags used to compile the sample program are `-march=armv8-a+crc+crypto -mtune=cortex-a53`. Crypto is enabled because the sample program is guarded by a runtime HasXXX() check. HasXXX() is a flag that is set by exercising the instruction of interest guarded by a SIGILL handler.

Here's the output from Valgrind 3.11 built from sources. The program is Wei Dai's test driver program for Crypto++.

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

Testing Settings...

passed:  Your machine is little endian.
passed:  CRYPTOPP_ALLOW_UNALIGNED_DATA_ACCESS is not defined. Will restrict to aligned data access.
passed:  sizeof(byte) == 1
passed:  sizeof(word16) == 2
passed:  sizeof(word32) == 4
passed:  sizeof(word64) == 8
passed:  sizeof(hword) == 2, sizeof(word) == 4, sizeof(dword) == 8
disInstr(arm64): unhandled instruction 0x0EE0E020
disInstr(arm64): 0000'1110 1110'0000 1110'0000 0010'0000
==26380== valgrind: Unrecognised instruction at address 0x506e48.
==26380==    at 0x506E48: vmull_p64 (arm_neon.h:21482)
==26380==    by 0x506E48: CryptoPP::TryPMULL() (cpu.cpp:484)
==26380==    by 0x5072EB: CryptoPP::DetectArmFeatures() (cpu.cpp:740)
==26380==    by 0x4A09EF: HasNEON (cpu.h:331)
==26380==    by 0x4A09EF: TestSettings() (validat1.cpp:317)
==26380==    by 0x4A7D0B: ValidateAll(bool) (validat1.cpp:75)
==26380==    by 0x490083: Validate(int, bool, char const*) (test.cpp:889)
==26380==    by 0x458B8F: main (test.cpp:358)
==26380== Your program just tried to execute an instruction that Valgrind
==26380== did not recognise.  There are two possible reasons for this...
ARM64 front end: data_processing_register

disInstr(arm64): unhandled instruction 0x1AC15800
disInstr(arm64): 0001'1010 1100'0001 0101'1000 0000'0000
==26380== valgrind: Unrecognised instruction at address 0x506f98.
==26380==    at 0x506F98: __crc32cw (arm_acle.h:57)
==26380==    by 0x506F98: CryptoPP::TryCRC32() (cpu.cpp:543)
==26380==    by 0x5072FB: CryptoPP::DetectArmFeatures() (cpu.cpp:741)
==26380==    by 0x4A09EF: HasNEON (cpu.h:331)
==26380==    by 0x4A09EF: TestSettings() (validat1.cpp:317)
==26380==    by 0x4A7D0B: ValidateAll(bool) (validat1.cpp:75)
==26380==    by 0x490083: Validate(int, bool, char const*) (test.cpp:889)
==26380==    by 0x458B8F: main (test.cpp:358)
==26380== Your program just tried to execute an instruction that Valgrind
==26380== did not recognise.  There are two possible reasons for this...

disInstr(arm64): unhandled instruction 0x4E284801
disInstr(arm64): 0100'1110 0010'1000 0100'1000 0000'0001
==26380== valgrind: Unrecognised instruction at address 0x507058.
==26380==    at 0x507058: vaeseq_u8 (arm_neon.h:13731)
==26380==    by 0x507058: CryptoPP::TryAES() (cpu.cpp:597)
==26380==    by 0x50730B: CryptoPP::DetectArmFeatures() (cpu.cpp:742)
==26380==    by 0x4A09EF: HasNEON (cpu.h:331)
==26380==    by 0x4A09EF: TestSettings() (validat1.cpp:317)
==26380==    by 0x4A7D0B: ValidateAll(bool) (validat1.cpp:75)
==26380==    by 0x490083: Validate(int, bool, char const*) (test.cpp:889)
==26380==    by 0x458B8F: main (test.cpp:358)
==26380== Your program just tried to execute an instruction that Valgrind
==26380== did not recognise.  There are two possible reasons for this....

disInstr(arm64): unhandled instruction 0x5E040023
disInstr(arm64): 0101'1110 0000'0100 0000'0000 0010'0011
==26380== valgrind: Unrecognised instruction at address 0x507130.
==26380==    at 0x507130: vsha1cq_u32 (arm_neon.h:21423)
==26380==    by 0x507130: CryptoPP::TrySHA1() (cpu.cpp:654)
==26380==    by 0x50731B: CryptoPP::DetectArmFeatures() (cpu.cpp:743)
==26380==    by 0x4A09EF: HasNEON (cpu.h:331)
==26380==    by 0x4A09EF: TestSettings() (validat1.cpp:317)
==26380==    by 0x4A7D0B: ValidateAll(bool) (validat1.cpp:75)
==26380==    by 0x490083: Validate(int, bool, char const*) (test.cpp:889)
==26380==    by 0x458B8F: main (test.cpp:358)
==26380== Your program just tried to execute an instruction that Valgrind
==26380== did not recognise.  There are two possible reasons for this...

disInstr(arm64): unhandled instruction 0x5E056060
disInstr(arm64): 0101'1110 0000'0101 0110'0000 0110'0000
==26380== valgrind: Unrecognised instruction at address 0x50725c.
==26380==    at 0x50725C: vsha256su1q_u32 (arm_neon.h:21475)
==26380==    by 0x50725C: CryptoPP::TrySHA2() (cpu.cpp:716)
==26380==    by 0x50732B: CryptoPP::DetectArmFeatures() (cpu.cpp:744)
==26380==    by 0x4A09EF: HasNEON (cpu.h:331)
==26380==    by 0x4A09EF: TestSettings() (validat1.cpp:317)
==26380==    by 0x4A7D0B: ValidateAll(bool) (validat1.cpp:75)
==26380==    by 0x490083: Validate(int, bool, char const*) (test.cpp:889)
==26380==    by 0x458B8F: main (test.cpp:358)
==26380== Your program just tried to execute an instruction that Valgrind
==26380== did not recognise.  There are two possible reasons for this...
...
Comment 1 Jeffrey Walton 2016-08-02 12:12:34 UTC
It looks like 3.12-SVN is missing the some of the instructions for the CRC32 checks:

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

Testing Settings...

passed:  Your machine is little endian.
passed:  CRYPTOPP_ALLOW_UNALIGNED_DATA_ACCESS is not defined. Will restrict to aligned data access.
passed:  sizeof(byte) == 1
passed:  sizeof(word16) == 2
passed:  sizeof(word32) == 4
passed:  sizeof(word64) == 8
passed:  sizeof(hword) == 2, sizeof(word) == 4, sizeof(dword) == 8
ARM64 front end: data_processing_register
disInstr(arm64): unhandled instruction 0x1AC15800
disInstr(arm64): 0001'1010 1100'0001 0101'1000 0000'0000
==9653== valgrind: Unrecognised instruction at address 0x506f98.
==9653==    at 0x506F98: __crc32cw (arm_acle.h:57)
==9653==    by 0x506F98: CryptoPP::TryCRC32() (cpu.cpp:543)
==9653==    by 0x5072FB: CryptoPP::DetectArmFeatures() (cpu.cpp:741)
==9653==    by 0x4A09EF: HasNEON (cpu.h:331)
==9653==    by 0x4A09EF: TestSettings() (validat1.cpp:317)
==9653==    by 0x4A7D0B: ValidateAll(bool) (validat1.cpp:75)
==9653==    by 0x490083: Validate(int, bool, char const*) (test.cpp:889)
==9653==    by 0x458B8F: main (test.cpp:358)
==9653== Your program just tried to execute an instruction that Valgrind
==9653== did not recognise.  There are two possible reasons for this.
==9653== 1. Your program has a bug and erroneously jumped to a non-code
==9653==    location.  If you are running Memcheck and you just saw a
==9653==    warning about a bad jump, it's probably your program's fault.
==9653== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9653==    i.e. it's Valgrind's fault.  If you think this is the case or
==9653==    you are not sure, please let us know and we'll try to fix it.
==9653== Either way, Valgrind will now raise a SIGILL signal which will
==9653== probably kill your program.
...
Comment 2 Julian Seward 2016-08-02 16:59:48 UTC
Try using the trunk.  That supports all the crypto instructions in 64-bit mode.
Comment 3 Julian Seward 2016-08-02 17:01:06 UTC
Ah, sorry, I failed to read comment 1.
Comment 4 Julian Seward 2016-08-04 09:14:46 UTC
(In reply to Jeffrey Walton from comment #1)
> It looks like 3.12-SVN is missing the some of the instructions for the CRC32
> checks:

> ARM64 front end: data_processing_register
> disInstr(arm64): unhandled instruction 0x1AC15800
> disInstr(arm64): 0001'1010 1100'0001 0101'1000 0000'0000

Fixed, vex r3237.   All 8 of the CRC instructions should work now.
Comment 5 Julian Seward 2016-08-04 21:48:57 UTC
Test cases in r15924, 15925.
Comment 6 Jeffrey Walton 2016-08-04 23:05:09 UTC
(In reply to Julian Seward from comment #4)
> (In reply to Jeffrey Walton from comment #1)
> > It looks like 3.12-SVN is missing the some of the instructions for the CRC32
> > checks:
> 
> > ARM64 front end: data_processing_register
> > disInstr(arm64): unhandled instruction 0x1AC15800
> > disInstr(arm64): 0001'1010 1100'0001 0101'1000 0000'0000
> 
> Fixed, vex r3237.   All 8 of the CRC instructions should work now.

Thank you very much. Confirmed the fix; close it.