Bug 396001 - unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto 'mrrc'
Summary: unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto 'mrrc'
Status: RESOLVED DUPLICATE of bug 344802
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.13.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
: 397256 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-06-29 15:51 UTC by John Reiser
Modified: 2018-09-03 09:40 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Reiser 2018-06-29 15:51:29 UTC
On 32-bit ARMv7 the file libcrypto.so.1.1 in package openssl-libs tries to execute 0xEC51 0x0F1E which is "mrrc	p15,0,r0,r1,c14".  valgrind does not handle this instruction.  The instruction is part of subroutine _armv7_tick() called from OPENSSL_cpuid_setup() to interrogate the hardware capabilities of the cpu.

Please handle this instruction.
Comment 1 Peter Maydell 2018-06-29 16:02:00 UTC
0xEC510F1E is actually "mrrc	p15,1,r0,r1,c14", which is an access to CNTVCT. I think this is a duplicate of #344802.
Comment 2 John Reiser 2018-06-30 01:00:25 UTC
OK, it's the same as #344802.  It would be nice to fix a bug that is 2.5 to 3 years old, depending on how you count.  Anyone who uses libcrypto.so.1.1 on ARM will stumble on this bug.

The [valgrind-users] report "Valgrind on arm system startup message" of Thu, 28 Jun 2018 20:21:05 -0400 gives some distracting information:
=====
==621== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==621== Command: ./myprogram
==621==
disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
==621== valgrind: Unrecognised instruction at address 0x4cc1767.
==621==    at 0x4CC1766: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1) 
=====

Notice that it says "thumb", with a not-even PC address 0x4cc1767, and that the disassembly is two 16-bit words instead of one 32-bit word.  Fooled me.

*** This bug has been marked as a duplicate of bug 344802 ***
Comment 3 Julian Seward 2018-09-03 09:40:31 UTC
*** Bug 397256 has been marked as a duplicate of this bug. ***