But I can't execute it natively either (on cortex-a15):

(gdb) run
Starting program: /space1/VgTRUNK/trunk/bug344802 

Program received signal SIGILL, Illegal instruction.
0x000083cc in main ()
(gdb) disp /i $pc
1: x/i $pc
=> 0x83cc <main+8>:	mrrc	15, 1, r0, r1, cr14

i meet the same probrom, can you give me the code how to decode the mrrc instr?

i meet the same probrom, can you give me the code how to decode the mrrc instr?

i meet the same probrom, can you give me the code how to decode the mrrc instr?

(In reply to Julian Seward from comment #1)
> But I can't execute it natively either (on cortex-a15):

More recent kernels expose the virtual counter to userspace (*); this is really intended for the VDSO to use and last I asked it wasn't intended as a general user-facing ABI, but the insn will succeed and so it's likely code will end up using it... 

(*) http://lxr.free-electrons.com/source/drivers/clocksource/arm_arch_timer.c#L331

I am facing the same issue. 
I am using valgrind on a Android system service. This is the 3.10.1 release.
I can execute it natively without problem. But not with valgrind.

I get this log:

==26688== Memcheck, a memory error detector
==26688== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26688== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==26688== Command: surfaceflinger
==26688== 
WARNING: linker: Unsupported flags DT_FLAGS_1=0x421
disInstr(arm): unhandled instruction: 0xEC510F1E
                 cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE)
==26688== valgrind: Unrecognised instruction at address 0x5534b48.
==26688==    at 0x5534B48: _armv7_tick (in /system/lib/libcrypto.so)
==26688== Your program just tried to execute an instruction that Valgrind
==26688== did not recognise.  There are two possible reasons for this.
==26688== 1. Your program has a bug and erroneously jumped to a non-code
==26688==    location.  If you are running Memcheck and you just saw a
==26688==    warning about a bad jump, it's probably your program's fault.
==26688== 2. The instruction is legitimate but Valgrind doesn't handle it,
==26688==    i.e. it's Valgrind's fault.  If you think this is the case or
==26688==    you are not sure, please let us know and we'll try to fix it.
==26688== Either way, Valgrind will now raise a SIGILL signal which will
==26688== probably kill your program.
disInstr(arm): unhandled instruction: 0xEE190F1D
                 cond=14(0xE) 27:20=225(0xE1) 4:4=1 3:0=13(0xD)
==26688== valgrind: Unrecognised instruction at address 0x55d0d08.
==26688==    at 0x55D0D08: _fips_armv7_tick (in /system/lib/libcrypto.so)
==26688== Your program just tried to execute an instruction that Valgrind
==26688== did not recognise.  There are two possible reasons for this.
==26688== 1. Your program has a bug and erroneously jumped to a non-code
==26688==    location.  If you are running Memcheck and you just saw a
==26688==    warning about a bad jump, it's probably your program's fault.
==26688== 2. The instruction is legitimate but Valgrind doesn't handle it,
==26688==    i.e. it's Valgrind's fault.  If you think this is the case or
==26688==    you are not sure, please let us know and we'll try to fix it.
==26688== Either way, Valgrind will now raise a SIGILL signal which will
==26688== probably kill your program.

==26688== Syscall param prctl(arg5) contains uninitialised byte(s)
==26688==    at 0x48CD97C: prctl (in /system/lib/libc.so)
==26688==    by 0x49A338D: set_sched_policy (in /system/lib/libcutils.so)
....

I have the same issue.
What's the status of this problem ? (or how can I help to fix this issue)
(I just run `ls` with Nulgrind on Android)

log :

==19886== Nulgrind, the minimal Valgrind tool
==19886== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote.
==19886== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==19886== Command: ls bin
==19886== Parent PID: 19832
==19886== 
--19886-- 
--19886-- Valgrind options:
--19886--    --verbose
--19886--    --log-file=/sdcard/logfile
--19886--    --tool=none
--19886-- Contents of /proc/version:
--19886--   Linux version 3.4.0-oc-ga94165f (build@ndj) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed Jul 1 15:02:21 EDT 2015
--19886-- 
--19886-- Arch and hwcaps: ARM, LittleEndian, ARMv7-neon-vfp
--19886-- Page sizes: currently 4096, max supported 4096
--19886-- Valgrind library directory: /data/local/Inst/lib/valgrind
--19886-- Reading syms from /system/bin/toolbox
--19886--    object doesn't have a symbol table
--19886--   Reading EXIDX entries: 249 available
--19886--   Reading EXIDX entries: 247 attempted, 247 successful
--19886-- Reading syms from /system/bin/linker
--19886-- Reading syms from /data/local/Inst/lib/valgrind/none-arm-linux
--19886--    object doesn't have a dynamic symbol table
--19886-- Scheduler: using generic scheduler lock implementation.
--19886-- Reading syms from /data/local/Inst/lib/valgrind/vgpreload_core-arm-linux.so
--19886-- Reading syms from /system/lib/libc.so
--19886-- Reading syms from /system/lib/libcrypto.so
--19886--    object doesn't have a symbol table
--19886--   Reading EXIDX entries: 2671 available
==19886==   Warning: whilst reading EXIDX: Implausible EXIDX last entry size 6387; using 1 instead.
--19886--   Reading EXIDX entries: 2670 attempted, 2670 successful
--19886-- Reading syms from /system/lib/libcutils.so
--19886--    object doesn't have a symbol table
--19886-- Reading syms from /system/lib/libm.so
--19886--    object doesn't have a symbol table
--19886--   Reading EXIDX entries: 156 available
==19886==   Warning: whilst reading EXIDX: ExtabEntryDecode: failed with error code: -10
==19886==   Warning: whilst reading EXIDX: ExtabEntryDecode: failed with error code: -10
==19886==   Warning: whilst reading EXIDX: ExtabEntryDecode: failed with error code: -10
--19886--   Reading EXIDX entries: 155 attempted, 152 successful
--19886-- Reading syms from /system/lib/libselinux.so
--19886--    object doesn't have a symbol table
--19886--   Reading EXIDX entries: 157 available
--19886--   Reading EXIDX entries: 155 attempted, 155 successful
--19886-- Reading syms from /system/lib/libstdc++.so
--19886--    object doesn't have a symbol table
--19886--   Reading EXIDX entries: 17 available
--19886--   Reading EXIDX entries: 16 attempted, 16 successful
--19886-- Reading syms from /system/lib/liblog.so
--19886--    object doesn't have a symbol table
--19886--   Reading EXIDX entries: 56 available
--19886--   Reading EXIDX entries: 55 attempted, 55 successful
--19886-- Reading syms from /system/lib/libpcre.so
--19886--    object doesn't have a symbol table
--19886--   Reading EXIDX entries: 51 available
--19886--   Reading EXIDX entries: 49 attempted, 49 successful
--19886-- Reading syms from /system/lib/libnetd_client.so
--19886--    object doesn't have a symbol table
--19886--   Reading EXIDX entries: 20 available
--19886--   Reading EXIDX entries: 19 attempted, 19 successful
disInstr(arm): unhandled instruction: 0xEC510F1E
                 cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE)
==19886== valgrind: Unrecognised instruction at address 0x48cf988.
==19886==    at 0x48CF988: _armv7_tick (in /system/lib/libcrypto.so)
==19886== Your program just tried to execute an instruction that Valgrind
==19886== did not recognise.  There are two possible reasons for this.
==19886== 1. Your program has a bug and erroneously jumped to a non-code
==19886==    location.  If you are running Memcheck and you just saw a
==19886==    warning about a bad jump, it's probably your program's fault.
==19886== 2. The instruction is legitimate but Valgrind doesn't handle it,
==19886==    i.e. it's Valgrind's fault.  If you think this is the case or
==19886==    you are not sure, please let us know and we'll try to fix it.
==19886== Either way, Valgrind will now raise a SIGILL signal which will
==19886== probably kill your program.
==19886==

Disable SIGILL reporting. Aparently "libcrypto.so" launches a SIGILL on purpose...
Dont know why. Probably to kill any app that is trying to read raw encrypted data. But without valgrind the SIGILL is cached and the program recovers without problem.

But calling valgrind with "--sigill-diagnostics=no", fixes the issue.

This should be a recomended solution by valgrind. but it is not....
Someone can add it to the "Possible reasons in Valgrind log" ?

It's more likely that libcrypto is probing to see what intructions the CPU supports so it can decide what variant to use for a hand coded assembly routine.

Created attachment 98873 [details]
increase the decode about mrrc in VEX/priv/guest_arm_toIR.c

in guest_arm_toIR.c:17257 lines
I increase the decode about mrrc :
/*mrrc     p15, 1, r0,  r1, c14  */
   if (0xEC510F1E == (insn & 0xFFF00FFF)) {
      UInt rK = INSN(15,12);
      UInt rM = INSN(19,16);
      if (rK <= 14&&rM <= 14) {
         putIRegA(rK, mkU32(0), condT, Ijk_Boring);
         putIRegA(rM, mkU32(0), condT, Ijk_Boring);
         DIP("mrrc p15,1,r%u,r%u,r1,c14\n",rM,rK);
         goto decode_success;
      }
   }

sorry , (0xEC510F1E == (insn & 0xFFF00FFF)) must  modifiy  as
          (0xEC510F1E == (insn & 0xFFFF0FFF))

Created attachment 98894 [details]
increae the decode of mrrc in guest_arm_toIR.c

Created attachment 101694 [details]
Add decode for CNTVCT, CNTPCT, and CNTFRQ

I've attached a patch that adds decode support for CNTVCT, CNTPCT, and CNTFRQ using helpers to execute the real instructions.  It is based on the ARMv8 support for the CNTVCT register.

The patch that is already attached supports only CNTVCT, and hardcodes the value to 0, which breaks many use cases.

*** Bug 377420 has been marked as a duplicate of this bug. ***

*** Bug 396001 has been marked as a duplicate of this bug. ***

(In reply to Matt Cowell from comment #13)
> Created attachment 101694 [details]
> Add decode for CNTVCT, CNTPCT, and CNTFRQ
Today the patch now lives at https://bugsfiles.kde.org/attachment.cgi?id=101694 and does apply, with offsets:
$ patch -p1 <344802-101694.patch
patching file VEX/priv/guest_arm_defs.h
Hunk #1 succeeded at 350 (offset 112 lines).
patching file VEX/priv/guest_arm_helpers.c
Hunk #1 succeeded at 1445 (offset 258 lines).
patching file VEX/priv/guest_arm_toIR.c
Hunk #1 succeeded at 18755 (offset 1500 lines).
Hunk #2 succeeded at 23277 (offset 1548 lines).

However the patch does not compile on arm64(aarch64):
priv/guest_arm_helpers.c: In function ‘arm_dirtyhelper_MRRS_CNTVCT’:
priv/guest_arm_helpers.c:1458:4: error: invalid 'asm': invalid operand prefix '%Q'
    __asm__ __volatile__("mrrc p15, 1, %Q0, %R0, c14" : "=r"(w));
    ^~~~~~~
priv/guest_arm_helpers.c:1458:4: error: invalid 'asm': incompatible floating point / vector register operand for '%R'

Created attachment 113695 [details]
patch to read timer tick registers on arm32, arm64

native for both arm32 and arm64

Created attachment 113735 [details]
patch to read timer tick registers on arm, arm64

fix typo in previous version 11695 of patch

Validated OK on the build git : 

commit 4c9bd311660bf4c1f9228519223214b6a50935ec 
from   Wed Mar 21 23:24:09 2018 +0100