[Valgrind-users] hi, there is an unknown instruction in arm32 mode. Does valgrind not support strmi instr?

[Wuweijia]

localhost:/system/bin # ./valgrind -v ./testDhat32
==23313== Memcheck, a memory error detector
==23313== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==23313== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==23313== Command: ./testDhat32
==23313==
--23313-- Valgrind options:
--23313-- -v
--23313-- Contents of /proc/version:
--23313-- Linux version 4.4.7+ (***@baixin-HP-Compaq-8200-Elite-MT-PC) (gcc version 4.9.3 20151223 (prerelease) (SDK V100R005C00SPC030B080) ) #1 SMP PREEMPT Fri Sep 9 14:57:05 CST 2016
--23313--
--23313-- Arch and hwcaps: ARM, LittleEndian, ARMv8-neon-vfp
--23313-- Page sizes: currently 4096, max supported 4096
--23313-- Valgrind library directory: /system/lib64/valgrind
--23313-- Reading syms from /system_O/bin/testDhat32
--23313-- Reading syms from /system_O/bin/linker
--23313-- Reading syms from /system_O/lib64/valgrind/memcheck-arm-linux
--23313-- object doesn't have a dynamic symbol table
--23313-- Scheduler: using generic scheduler lock implementation.
--23313-- Reading suppressions file: /system/lib64/valgrind/default.supp
disInstr(thumb): unhandled instruction: 0x450B 0xD104 0x450B 0xD104 => strmi Does valgrind not support strmi instr?
==23313== valgrind: Unrecognised instruction at address 0x4108187.
==23313== at 0x4108186: __pthread_normal_mutex_trylock (pthread_mutex.cpp:281)
==23313== by 0x4108186: __dl_pthread_mutex_lock (pthread_mutex.cpp:520)
==23313== by 0x407C6A9: __libcpp_mutex_lock (__threading_support:251)
==23313== by 0x407C6A9: __dl___cxa_guard_acquire (cxa_guard.cpp:176)
==23313== by 0x41136EF: __dl__Z39__libc_arc4random_has_unlimited_entropyv (bionic_arc4random.cpp:42)
==23313== by 0x4113759: __dl__Z26__libc_safe_arc4random_bufPvjR19KernelArgumentBlock (bionic_arc4random.cpp:49)
==23313== by 0x4109831: __dl__Z34__libc_init_global_stack_chk_guardR19KernelArgumentBlock (__libc_init_main_thread.cpp:45)
==23313== by 0x41098A5: __dl__Z23__libc_init_main_threadR19KernelArgumentBlock (__libc_init_main_thread.cpp:94)
==23313== by 0x402F63B: __dl___linker_init (linker_main.cpp:525)
==23313== by 0x403EA63: _start (begin.S:33)
==23313== by 0x403EA63: _start (begin.S:33)
==23313== by 0x403EA63: _start (begin.S:33)
==23313== by 0x403EA63: _start (begin.S:33)
==23313== by 0x403EA63: _start (begin.S:33)
==23313== Your program just tried to execute an instruction that Valgrind
==23313== did not recognise. There are two possible reasons for this.
==23313== 1. Your program has a bug and erroneously jumped to a non-code
==23313== location. If you are running Memcheck and you just saw a
==23313== warning about a bad jump, it's probably your program's fault.
==23313== 2. The instruction is legitimate but Valgrind doesn't handle it,
==23313== i.e. it's Valgrind's fault. If you think this is the case or
==23313== you are not sure, please let us know and we'll try to fix it.
==23313== Either way, Valgrind will now raise a SIGILL signal which will
==23313== probably kill your program.


Env: Android O version
CPU Aarch64
EABI: 5 (I compile it in arm32 mode)

The source file as below:
int main(int argc, char *argv[])
{
Return 0;
}

[John Reiser]

Post by Wuweijia
disInstr(thumb): unhandled instruction: 0x450B 0xD104 0x450B 0xD104 => strmi Does valgrind not support strmi instr?
==23313== valgrind: Unrecognised instruction at address 0x4108187.

The complaint says "(thumb)", and the address 0x4108187 is odd, so this looks like
Thumb mode, which is 16-bit instructions. There is no "strmi" opcode in the Thumb
instruction set. "strmi" would be a 32-bit instruction which is a conditional
"STore Register to memory if condition code is MInus (N bit (negative) set)".

Assembling and dis-assembling the program
===== foo.S
.short 0x450B, 0xD104
=====
$ gcc -c foo.S
$ gdb foo.o
(gdb) x/2i 1 ### 1: odd pc ==> thumb mode (16-bit instructions)
0x1: cmp r3, r1
0x3: bne.n 0xe

(gdb) x/i 0 ### 0: even pc ==> ARM mode (32-bit instructions)
0x0: tstle r4, r11, lsl #10

(gdb)

shows that "0x450B 0xD104" is not a 'strmi'.

Please use a debugger or other tool to inspect the instruction stream.
Show the surrounding bytes (16 bytes before, 16 bytes after)
in both hex and decoded instructions.

--