Hi Wookey ! On Wed, Jun 29, 2022 at 2:48 PM Wookey <woo...@wookware.org> wrote: > > On 2022-06-29 08:54 +0200, Mathieu Malaterre wrote: > > [cc me please] > > > > Dear armhf gurus, > > > > Could someone please confirm that abel.d.o hardware is almost like a > > good old RaspberryPi Model 2B ? I am trying to understand why valgrind > > is supposed to work on arm32/linux but fails miserably on abel.d.o. > > Abel is a marvell Armada 370/XP CPU (4 cores) in the form of an MV78460 dev > board. > Marvell have their own architecture licence so it's not an ARM (the company) > design) > > It has these CPU features: > half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae > > so that means it doesn't have neon, which would trip up code assuming that it > doesn. > It's also a v7 core. > > The RPi Model2B was oringally a Broadcom BCM2836 (quadcore Cortex-A7) > and later (v1.2) was a BCM2837 (quadcore Cortex A53) (Both ARM (the > company) core designs, but A53 is v8 and A7 is v7 ISA). > > So abel and the original RPi 2B are similar in that both are v7, 4-core > CPUs. But they have different HWCAPS and microarchitectures. (And the > later A53/BCM2837 is quite different with a 64-bit v8 CPU) > > I'm failing to find the /proc/cpuinfo or HWCAPS spec for the cortex > A7, but it does have neon, so no they are not 'the same'. If you want > to see if this is the issue, try the 'harris' porterbox, which is > different v7 32-bit CPU (Freeescale i.MX53), but does have neon. > > What exactly is going wrong when you try to use valgrind?
Well you should see something like this on abel.d.o: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224#27 Basically anytime you build valgrind using gcc-11 or gcc-12 (debian sid package), you get this weird illegal instruction: ``` % ./vg-in-place Illegal instruction ``` The debian package seems to be affected as well: malat@abel ~ % valgrind /bin/true zsh: illegal hardware instruction valgrind /bin/true Discussing the issue with upstream seems to only lead to the following exchange: * https://sourceforge.net/p/valgrind/mailman/message/37674159/ [...] So YES, current valgrind does support armhf (armv7l: 32-bit, hard floating point). [...] which makes it hard to report the actual issue upstream. I am not familiar with such low level issues so I fail to actually prepare an accurate/complete bug report. I also tested on harris, and valgrind seems to be running just fine: harris% valgrind /bin/true ==26697== Memcheck, a memory error detector ==26697== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==26697== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==26697== Command: /bin/true ==26697== ==26697== ==26697== HEAP SUMMARY: ==26697== in use at exit: 0 bytes in 0 blocks ==26697== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==26697== ==26697== All heap blocks were freed -- no leaks are possible ==26697== ==26697== For lists of detected and suppressed errors, rerun with: -s ==26697== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
