On 06/28/2018, Edward Diener wrote:
I am attempting to use Valgrind with an application on an embedded arm system.
==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)
Dis-assembling the one-line program
.short 0xEC51,0x0F1E
in Thumb mode [using: (gdb) x/i 1 ] gives
mrrc 15,1,r0,r1,cr14
which is moving data from co-processor 15 register cr14 into registers r0 and
r1.
If the "libcrypto.so.1.1" return address is a correct hint,
then this is some cryptography code checking for the presence of hardware
assist.
You could be more sure of this by dis-assembling several instructions
before and after 0x4CC1766, and by looking at the source code for
libcrypto.so.1.1.
The actual bits returned by the mrrc instruction depend on the exact model of
the CPU.
What does "cat /proc/cpuinfo" say?
Valgrind does not know enough about your CPU chip.
You can help by filing a bug report; see
http://valgrind.org/support/bug_reports.html .
Be sure to include the version of your C-language run-time library
and how a valgrind developer can download your exact version of
libcrypto.so.1.1.
To make progress in the meantime, replace those 32 bits by the two instructions
mov r0,#0
mov r1,#0
which clear general registers r0 and r1. This is a guess that zeroes
mean "this CPU has no such hardware assist". The libcrypto software
will choose slower but equivalent code, instead of using
any special hardware assist.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
