Re: armhf: illegal hardware instruction

On Tue, Jun 28, 2022 at 8:55 PM John Reiser <[email protected]> wrote:
>
> >> $ export RPI_MODEL=3
> >> $ export DEBIAN_RELEASE=bullseye
> >> $ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz
> >
> > That gives arm64, not armhf (32-bit).
>
> Choosing https://raspi.debian.net/tested/20220121_raspi_2_bullseye.img.xz
> and running    5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux
> on an old RaspberryPi Model 2B (32 bit, 1GB RAM, 4 CPU):
> -----
> model name      : ARMv7 Processor rev 5 (v7l)
> BogoMIPS        : 44.80
> Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x0
> CPU part        : 0xc07
> CPU revision    : 5
> -----
> with valgrind source
> -----
> commit 022dfeee73726d92ecc0349ebe42d7b52132b8e5 (HEAD -> master, origin/master, origin/HEAD)
> Author: Mark Wielaard <snip>
> Date:   Sat Jun 18 15:30:54 2022 +0200
> -----
> and ignoring a build failure
> -----
> Making install in tests
> make[3]: Entering directory '.../valgrind/cachegrind/tests'
> make[3]: *** No rule to make target 'install'.  Stop.
> -----
> then I see:
> -----
> $ ldd /bin/date
>         linux-vdso.so.1 (0xbeed6000)
>         libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e7a000)
>         /lib/ld-linux-armhf.so.3 (0xb6f9c000)
> $ type valgrind
> valgrind is hashed (/usr/local/bin/valgrind)
> $ valgrind --version
> valgrind-3.20.0.GIT
> $ valgrind /bin/date
> ==32179== Memcheck, a memory error detector
> ==32179== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==32179== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info
> ==32179== Command: /bin/date
> ==32179==
> Tue Jun 28 18:50:27 UTC 2022
> ==32179==
> ==32179== HEAP SUMMARY:
> ==32179==     in use at exit: 64 bytes in 1 blocks
> ==32179==   total heap usage: 9 allocs, 8 frees, 5,572 bytes allocated
> ==32179==
> ==32179== LEAK SUMMARY:
> ==32179==    definitely lost: 64 bytes in 1 blocks
> ==32179==    indirectly lost: 0 bytes in 0 blocks
> ==32179==      possibly lost: 0 bytes in 0 blocks
> ==32179==    still reachable: 0 bytes in 0 blocks
> ==32179==         suppressed: 0 bytes in 0 blocks
> ==32179== Rerun with --leak-check=full to see details of leaked memory
> ==32179==
> ==32179== For lists of detected and suppressed errors, rerun with: -s
> ==32179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> $
> -----

Point taken, I did not do my homework correctly, sorry for losing your time.

> So YES, current valgrind does support armhf (armv7l: 32-bit, hard floating point).

I did not make up those strace logs in my head, all I am trying to do
is Debian bug triaging. Turns out I did a pretty bad job at it:

1. The original Debian bug report seems to be PEBCAK, and I'll close
the bug as wontfix ASAP,
2. I was not paying attention to the gcc version I was using.

So if my understanding is correct I can make valgrind produce this
"Illegal instruction" using either gcc-11 or gcc-12 (Debian package
from sid), BUT I can make valgrind run using gcc-10 (again Debian
package from sid). This also seems to be hardware specific since armhf
binary + gcc-12 runs properly on arm64 (armhf chroot).

Would you kindly indicate if you believe the bug should be reported
back to valgrind bug tracker or gcc bug tracker ? If that matters,
clang 13.0 seems to also mess up valgrind code and binaries produced
return this "Illegal instruction".

Thanks for your time