Re: armhf: abel.d.o hardware status ?
Hi Wookey !
On Wed, Jun 29, 2022 at 2:48 PM Wookey <wookey@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)
Reply to: