On Tue, Jun 28, 2022 at 8:55 PM John Reiser <jrei...@bitwagon.com> 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 _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
