On 2022-06-29 15:13 +0200, Mathieu Malaterre wrote: > On Wed, Jun 29, 2022 at 2:48 PM Wookey <wookey@wookware.org> wrote: > > 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 > ``` I have a strong suspicion that this is neon-itis. The issue generally manifests as 'illegal instuction' (i.e a neon instruction is issued on hardware that isn't able to execute it). It has always been the case that software should not assume neon is present on v7 (because it isn't on all hardware), and most code gets this right, but I've recently seen gcc putting those instuctions into the startup code (where the C-environment is set up and variables allocated) which gets executed _before_ any functions checking for which HWCAPS to enable, and thus which code to run. You can check if a binary contains NEON instructions using readelf -A and look for Tag_Advanced_SIMD_arch: NEONv1 However just because its in the binary doesn't mean it's wrong. The binary may have been built using ifunc or other mechanisms to choose appropriate functions depending whether or not neon hardware is available. A simple check for whether this is your issue is just to run the same test on harris.debian.org. If it works OK there that strongly suggests you have a neon problem. Also if you run the program under gdb (on abel) and when it barfs do: (gdb) disassemble and look for instructions that start with 'v', like 'vmov.i32' that will confirm which instruction is tripping it up. This bug has an example of the problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998043 I got partway thorugh a long followup with some details of possible fixes some months ago but got sidetracked (and oh look it's been pending for 6 months already). The reason this has broken appears to be that gcc has changed the way the fpu is specified/defaulted, so neon _and_ fp are enabled by default if no specific fpu option is given. (i.e we just set -march=armv7). It used to be that -march=armv7 implied +nosimd. (or something like that - I never quite got to the bottom of it enough to be sure eactly what the right general or specific fix was). If you rebuild with -march=armv7-a+nosimd+nofp or -march=armv7-a+nosimd+fp you should be able to determine if being more explicit about the fp and simd(neon) instructions used makes it behave. It seems likely that you have hit this problem. I think this is the same thing too: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982794 (Firefox dying with illegal instruction on non-neon hardware) I _suspect_ that debian needs to change the default flags to actually say 'armv7+fp+nosimd' by default so that we get what we expect (and define as the base ISA) and it doesn't depend on what hardware the build was done on. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature