With the Arch Linux valgrind-3.13.0-2 and glibc-2.25-7 packages for
i686, no dynamically liked executables seem to work with Valgrind,
because glibc's ld-*.so contains instructions that Valgrind can't
interpret.

    $ uname -a
    Linux thinkpadx60-par32.lan 4.11.12-gnu-1 #1 SMP PREEMPT Mon Jul 24 13:38:40 CEST 2017 i686 GNU/Linux

    $ valgrind -v /bin/ls
    ==29025== Memcheck, a memory error detector
    ==29025== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==29025== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
    ==29025== Command: /bin/ls
    ==29025== 
    --29025-- Valgrind options:
    --29025--    -v
    --29025-- Contents of /proc/version:
    --29025--   Linux version 4.11.12-gnu-1 (builduser@ebrasca) (gcc version 7.1.1 20170621 (GCC) ) #1 SMP PREEMPT Mon Jul 24 13:38:40 CEST 2017
    --29025-- 
    --29025-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3
    --29025-- Page sizes: currently 4096, max supported 4096
    --29025-- Valgrind library directory: /usr/lib/valgrind
    --29025-- Reading syms from /usr/lib/ld-2.25.so
    --29025-- Reading syms from /usr/bin/ls
    --29025--    object doesn't have a symbol table
    --29025-- Reading syms from /usr/lib/valgrind/memcheck-x86-linux
    --29025--    object doesn't have a symbol table
    --29025--    object doesn't have a dynamic symbol table
    --29025-- Scheduler: using generic scheduler lock implementation.
    --29025-- Reading suppressions file: /usr/lib/valgrind/default.supp
    ==29025== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-29025-by-lukeshu-on-???
    ==29025== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-29025-by-lukeshu-on-???
    ==29025== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-29025-by-lukeshu-on-???
    ==29025== 
    ==29025== TO CONTROL THIS PROCESS USING vgdb (which you probably
    ==29025== don't want to do, unless you know exactly what you're doing,
    ==29025== or are doing some strange experiment):
    ==29025==   /usr/lib/valgrind/../../bin/vgdb --pid=29025 ...command...
    ==29025== 
    ==29025== TO DEBUG THIS PROCESS USING GDB: start GDB like this
    ==29025==   /path/to/gdb /bin/ls
    ==29025== and then give GDB the following command
    ==29025==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=29025
    ==29025== --pid is optional if only one valgrind process is running
    ==29025== 
    --29025-- REDIR: 0x4019570 (ld-linux.so.2:strlen) redirected to 0x58057083 (???)
    vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x6B 0x6A
    ==29025== valgrind: Unrecognised instruction at address 0x4002e2f.
    ==29025==    at 0x4002E2F: dl_main (in /usr/lib/ld-2.25.so)
    ==29025==    by 0x4016A25: _dl_sysdep_start (in /usr/lib/ld-2.25.so)
    ==29025==    by 0x4001861: _dl_start (in /usr/lib/ld-2.25.so)
    ==29025==    by 0x4000AF6: ??? (in /usr/lib/ld-2.25.so)
    ==29025== Your program just tried to execute an instruction that Valgrind
    ==29025== did not recognise.  There are two possible reasons for this.
    ==29025== 1. Your program has a bug and erroneously jumped to a non-code
    ==29025==    location.  If you are running Memcheck and you just saw a
    ==29025==    warning about a bad jump, it's probably your program's fault.
    ==29025== 2. The instruction is legitimate but Valgrind doesn't handle it,
    ==29025==    i.e. it's Valgrind's fault.  If you think this is the case or
    ==29025==    you are not sure, please let us know and we'll try to fix it.
    ==29025== Either way, Valgrind will now raise a SIGILL signal which will
    ==29025== probably kill your program.
    ==29025== 
    ==29025== Process terminating with default action of signal 4 (SIGILL): dumping core
    ==29025==  Illegal opcode at address 0x4002E2F
    ==29025==    at 0x4002E2F: dl_main (in /usr/lib/ld-2.25.so)
    ==29025==    by 0x4016A25: _dl_sysdep_start (in /usr/lib/ld-2.25.so)
    ==29025==    by 0x4001861: _dl_start (in /usr/lib/ld-2.25.so)
    ==29025==    by 0x4000AF6: ??? (in /usr/lib/ld-2.25.so)
    ==29025== 
    ==29025== HEAP SUMMARY:
    ==29025==     in use at exit: 0 bytes in 0 blocks
    ==29025==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
    ==29025== 
    ==29025== All heap blocks were freed -- no leaks are possible
    ==29025== 
    ==29025== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    ==29025== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    Illegal instruction (core dumped)