SUMMARY For almost all terminals which compile sources, valgrind has lots of uses. But with Android OS (Termux is the closest this has to Bash/Ash), valgrind always outputs Unrecognized instruction at address X STEPS TO REPRODUCE ``` Welcome to Termux! Docs: https://termux.dev/docs ~ $ valgrind /bin/ls ``` OBSERVED RESULT ``` ==14222== Memcheck, a memory error detector ==14222== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==14222== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==14222== Command: /bin/ls ==14222== ARM64 front end: load_store disInstr(arm64): unhandled instruction 0x38BFC109 disInstr(arm64): 0011'1000 1011'1111 1100'0001 0000'1001 ==14222== valgrind: Unrecognised instruction at address 0x4073170. ==14222== at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64) ==14222== by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64) ==14222== by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64) ==14222== by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64) ==14222== by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64) ==14222== Your program just tried to execute an instruction that Valgrind ==14222== did not recognise. There are two possible reasons for this. ==14222== 1. Your program has a bug and erroneously jumped to a non-code ==14222== location. If you are running Memcheck and you just saw a ==14222== warning about a bad jump, it's probably your program's fault. ==14222== 2. The instruction is legitimate but Valgrind doesn't handle it, ==14222== i.e. it's Valgrind's fault. If you think this is the case or ==14222== you are not sure, please let us know and we'll try to fix it. ==14222== Either way, Valgrind will now raise a SIGILL signal which will ==14222== probably kill your program. ==14222== ==14222== Process terminating with default action of signal 4 (SIGILL) ==14222== Illegal opcode at address 0x4073170 ==14222== at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64) ==14222== by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64) ==14222== by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64) ==14222== by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64) ==14222== by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64) ==14222== ==14222== HEAP SUMMARY: ==14222== in use at exit: 0 bytes in 0 blocks ==14222== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==14222== ==14222== All heap blocks were freed -- no leaks are possible ==14222== ==14222== For lists of detected and suppressed errors, rerun with: -s ==14222== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction ~ $ ``` STEPS TO REPRODUCE ``` ~ $ cat a.cxx int main(int, const char **) { return 0; } ~ $ clang++ a.cxx ~ $ ./a.out ~ $ valgrind ./a.out ``` OBSERVED RESULT ``` ==8263== Memcheck, a memory error detector ==8263== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==8263== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==8263== Command: ./a.out ==8263== ARM64 front end: load_store disInstr(arm64): unhandled instruction 0x38BFC109 disInstr(arm64): 0011'1000 1011'1111 1100'0001 0000'1001 ==8263== valgrind: Unrecognised instruction at address 0x4073170. ==8263== at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64) ==8263== by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64) ==8263== by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64) ==8263== by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64) ==8263== by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64) ==8263== Your program just tried to execute an instruction that Valgrind ==8263== did not recognise. There are two possible reasons for this. ==8263== 1. Your program has a bug and erroneously jumped to a non-code ==8263== location. If you are running Memcheck and you just saw a ==8263== warning about a bad jump, it's probably your program's fault. ==8263== 2. The instruction is legitimate but Valgrind doesn't handle it, ==8263== i.e. it's Valgrind's fault. If you think this is the case or ==8263== you are not sure, please let us know and we'll try to fix it. ==8263== Either way, Valgrind will now raise a SIGILL signal which will ==8263== probably kill your program. ==8263== ==8263== Process terminating with default action of signal 4 (SIGILL) ==8263== Illegal opcode at address 0x4073170 ==8263== at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64) ==8263== by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64) ==8263== by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64) ==8263== by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64) ==8263== by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64) ==8263== ==8263== HEAP SUMMARY: ==8263== in use at exit: 0 bytes in 0 blocks ==8263== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==8263== ==8263== All heap blocks were freed -- no leaks are possible ==8263== ==8263== For lists of detected and suppressed errors, rerun with: -s ==8263== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction ~ $ ``` EXPECTED RESULT ``` ==8263== Memcheck, a memory error detector ==8263== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==8263== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==8263== Command: ./a.out ==8263== ARM64 front end: load_store ==8263== HEAP SUMMARY: ==8263== in use at exit: 0 bytes in 0 blocks ==8263== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==8263== ==8263== All heap blocks were freed -- no leaks are possible ==8263== ==8263== For lists of detected and suppressed errors, rerun with: -s ==8263== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ~ $ ``` SOFTWARE/OS VERSIONS ```~ $ termux-info Welcome to Termux! Docs: https://termux.dev/docs Donate: https://termux.dev/donate Community: https://termux.dev/community Working with packages: - Search: pkg search <query> - Install: pkg install <package> - Upgrade: pkg upgrade Subscribing to additional repositories: - Root: pkg install root-repo - X11: pkg install x11-repo For fixing any repository issues, try 'termux-change-repo' command. Report issues at https://termux.dev/issues ~/SubStack $ vim ~/todo ~/SubStack $ termux-info Termux Variables: TERMUX_APK_RELEASE=F_DROID TERMUX_APP_PACKAGE_MANAGER=apt TERMUX_APP_PID=30205 TERMUX_IS_DEBUGGABLE_BUILD=0 TERMUX_MAIN_PACKAGE_FORMAT=debian TERMUX_VERSION=0.118.0 TERMUX__USER_ID=0 Packages CPU architecture: aarch64 Subscribed repositories: # sources.list deb https://packages.termux.dev/apt/termux-main stable main Updatable packages: All packages up to date termux-tools version: 1.42.4 Android version: 14 Kernel build information: Linux localhost 5.10.189-android13-4-00012-g1217bb583cc5-ab11174560 #1 SMP PREEMPT Mon Dec 4 18:59:42 UTC 2023 aarch64 Android Device manufacturer: Google LD Variables: LD_LIBRARY_PATH= LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so ~/SubStack $ ``` ADDITIONAL INFORMATION https://github.com/ivosh/valgrind/issues/2
Termux devops: "[Is _Valgrind_'s issue to fix this]" https://github.com/termux/termux-packages/issues/20534#issuecomment-2167371271
This looks like ldaprb w9, [x8] which isn't supported (arm64 doesn't have much support of ARM 8.3)
As a workaround, if you target something like ARM8.2 (-march=armv8.2 maybe) then does it work?
(In reply to Paul Floyd from comment #3) > As a workaround, if you target something like ARM8.2 (-march=armv8.2 maybe) > then does it work? ``` ~ $ g++ -march=armv8.2 ~/a.cxx g++: error: unsupported argument 'armv8.2' to option '-march=' ```
``` ~ $ g++ -march=armv8.2-a ~/a.cxx ~ $ ./a.out ~ $ valgrind ./a.out ==19668== Memcheck, a memory error detector ==19668== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==19668== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==19668== Command: ./a.out ==19668== ARM64 front end: load_store disInstr(arm64): unhandled instruction 0x38BFC109 disInstr(arm64): 0011'1000 1011'1111 1100'0001 0000'1001 ==19668== valgrind: Unrecognised instruction at address 0x4073170. ==19668== at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64) ==19668== by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64) ==19668== by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64) ==19668== by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64) ==19668== by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64) ==19668== Your program just tried to execute an instruction that Valgrind ==19668== did not recognise. There are two possible reasons for this. ==19668== 1. Your program has a bug and erroneously jumped to a non-code ==19668== location. If you are running Memcheck and you just saw a ==19668== warning about a bad jump, it's probably your program's fault. ==19668== 2. The instruction is legitimate but Valgrind doesn't handle it, ==19668== i.e. it's Valgrind's fault. If you think this is the case or ==19668== you are not sure, please let us know and we'll try to fix it. ==19668== Either way, Valgrind will now raise a SIGILL signal which will ==19668== probably kill your program. ==19668== ==19668== Process terminating with default action of signal 4 (SIGILL) ==19668== Illegal opcode at address 0x4073170 ==19668== at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64) ==19668== by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64) ==19668== by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64) ==19668== by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64) ==19668== by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64) ==19668== ==19668== HEAP SUMMARY: ==19668== in use at exit: 0 bytes in 0 blocks ==19668== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==19668== ==19668== All heap blocks were freed -- no leaks are possible ==19668== ==19668== For lists of detected and suppressed errors, rerun with: -s ==19668== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction ~ $ ``` Must figure out how to rebuild `crt1.o` (other than empty `main()`, all this should have is `_start`) to 8.2?
I noticed this issue and tried implementing the instruction, since I wouldn't be able to install a rebuilt dynamic linker on my phone even if I *could* figure out how to rebuild it. See https://github.com/SamB/valgrind/commit/a4f98c8f617bab834dcf72725a4ac7a0844d3908 for my attempt. It sort of seems to work. There is also an issue with some transient mappings made by the dynamic linker tricking valgrind into unloading the debug info for shared libraries that are actually still loaded, which seems to go away if I apply the `Ignore non-fixed read-only mappings.` hack from FreeBSD to my situation as well... (Also, in my case I don't see symbols from linker64 because the machinery from bug 452802 isn't detecting that it has been completely loaded. I suspect "count the number of mappings" might not be a good approach to that problem?)
Can you keep trying with arm8 options to see if you can find a working combination?
(In reply to Paul Floyd from comment #7) > Can you keep trying with arm8 options to see if you can find a working > combination? Well, recompiling isn't a very practical option when the problem is in the dynamic linker, as it is here: (quoting Swudu Susuwu from comment #0) > ==14222== > ARM64 front end: load_store > disInstr(arm64): unhandled instruction 0x38BFC109 > disInstr(arm64): 0011'1000 1011'1111 1100'0001 0000'1001 > ==14222== valgrind: Unrecognised instruction at address 0x4073170. > ==14222== at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in > /apex/com.android.runtime/bin/linker64) > ==14222== by 0x4078377: __dl___libc_init_main_thread_late (in > /apex/com.android.runtime/bin/linker64) On Android, APEX files are APK files (but instead of a mobile app, there's an ext4 filesystem with dm-verity data with a signature that can be verified using a public key also in the APEX) and use APK signing to verify that the contents weren't tampered with. Anyway, this means the file is basically not user-patchable unless the firmware was built by the user in the first place. Theoretically, you could build your own copy of the linker, though I'm not sure there's a supported way to do that without building an entire AOSP image, and this wouldn't really work for multi-process scenarios without setting DT_INTERP in all relevant executables to point to the new build. Anyway, this appears to be a duplicate of bug 476465, which has a smaller patch attached. *** This bug has been marked as a duplicate of bug 476465 ***
(In reply to Samuel Bronson from comment #8) > (In reply to Paul Floyd from comment #7) > > Can you keep trying with arm8 options to see if you can find a working > > combination? > > Well, recompiling isn't a very practical option when the problem is in the > dynamic linker, as it is here: (quoting Swudu Susuwu from comment #0) Oh well. I don't develop for Android, and I don't think any of the other devs do either.