Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU
On 2021-12-08 20:11 +, peter green wrote: > The result of this change is if you manually set "-march" then it > overrides the built-in defaults for both the CPU and FPU rather than > only overriding the CPU. OK. That explains some things I've been noticing recently. > The default -march value on Debian armhf is "armv7-a+fp". You should Shouldn't it be "armv7-a+nosimd+fp", because neon is not assumed to be present on armhf? All neon code has to be gated on a HWCAP check, so the default should exclude it. I recently found a case where gcc11 helpfully put a neon optimisation into the init code of a complilation unit (zeroing variables), which of course means the program crashes on started on non-neon hardware. To be fair it only did that with -mfpu=neon set, but I'm not sure that it can't happen with a default march=armv7-a+fp OK. I just checked and in fact it doesn't do this optimisation if built with -march=armv7-a+fp so I guess there is an implicit assumption that everything not listed is disabled? Do we actually know for sure or shall I try and find out from some compiler engineers? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU
On 08/12/2021 23:56, Simon McVittie wrote: > On Wed, 08 Dec 2021 at 20:11:55 +, peter green wrote: >> The default -march value on Debian armhf is "armv7-a+fp". You should >> *NOT* use "armv7-a+vfpv3" as that specifies the version of vfpv3 >> with 32 double precision registers which is above the Debian baseline. > > https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e > (which I have now applied to the copy of cc-rs in mozjs78) uses > "-march=armv7-a -mfpu=vfpv3-d16", which seems like a plausible encoding of > the minimum spec given in https://wiki.debian.org/ArmHardFloatPort and > https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines > (ARMv7 with Thumb-2 and VFPv3-D16). Yes that is fine. > > If I understand correctly, VFPv3-D16 refers to the version of vfpv3 with > only 16 registers, which is exactly what our armhf baseline guarantees > (and as you point out, some ARM CPUs with VFPv3 have more registers, but we > require our binaries to assume those extra registers are not available). > Am I getting this right? Yes.
Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU
On Wed, 08 Dec 2021 at 20:11:55 +, peter green wrote: > The default -march value on Debian armhf is "armv7-a+fp". You should > *NOT* use "armv7-a+vfpv3" as that specifies the version of vfpv3 > with 32 double precision registers which is above the Debian baseline. https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e (which I have now applied to the copy of cc-rs in mozjs78) uses "-march=armv7-a -mfpu=vfpv3-d16", which seems like a plausible encoding of the minimum spec given in https://wiki.debian.org/ArmHardFloatPort and https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines (ARMv7 with Thumb-2 and VFPv3-D16). If I understand correctly, VFPv3-D16 refers to the version of vfpv3 with only 16 registers, which is exactly what our armhf baseline guarantees (and as you point out, some ARM CPUs with VFPv3 have more registers, but we require our binaries to assume those extra registers are not available). Am I getting this right? (And yes, in answer to the obvious question, it's not ideal that mozjs78 vendors lots of Rust modules, but I'm not aware of a way to un-vendor them in Mozilla's rather unique build system. Someone who knows Rust and/or mozjs better is welcome to step in any time.) smcv
Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU
On 08/12/2021 09:48, Simon McVittie wrote: On Wed, 08 Dec 2021 at 09:41:29 +, Simon McVittie wrote: At a guess, perhaps the problem is that the mozjs build system is explicitly specifying -march=armv7-a when it should be something like -march=armv7-a+vfpv3 or accepting the compiler's default? Looks like this might be the same issue fixed by https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e Certainly looks like it to me. The Debian gcc packages changed how they specify floating point options, they now use "-march" to set both the CPU and FPU rather than using seperate "-march" and "-mfpu" options. The result of this change is if you manually set "-march" then it overrides the built-in defaults for both the CPU and FPU rather than only overriding the CPU. If your new "-march" setting doesn't specify a FPU and you don't set a seperate "-mpfpu" option then you end up with an invalid configuration (hard float ABI selected but no FPU selected). The default -march value on Debian armhf is "armv7-a+fp". You should *NOT* use "armv7-a+vfpv3" as that specifies the version of vfpv3 with 32 double precision registers which is above the Debian baseline. https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU
On Wed, 08 Dec 2021 at 09:41:29 +, Simon McVittie wrote: > At a guess, perhaps the problem is that the mozjs build system is explicitly > specifying -march=armv7-a when it should be something like > -march=armv7-a+vfpv3 or accepting the compiler's default? Looks like this might be the same issue fixed by https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e smcv
Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU
Control: retitle -1 mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU Control: tags -1 + help On Wed, 08 Dec 2021 at 10:14:55 +0100, Fabio Fantoni wrote: > Hi, as can be see in reproducible tests > (https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/mozjs78.html) > latest mozjs78 fails to build on armhf in both sid and testing. > > https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/mozjs78_78.15.0-1.rbuild.log.gz > > https://tests.reproducible-builds.org/debian/rbuild/bookworm/armhf/mozjs78_78.15.0-1.rbuild.log.gz The source code hasn't changed since a version that built successfully, so this appears to be a regression triggered by some new toolchain package. armhf certainly does have a FPU - that's its defining feature when compared with armel. The error appears to be (shown wrapped here): > [mozglue-static 0.1.0] cargo:warning=cc1plus: error: '-mfloat-abi=hard': > selected architecture lacks an FPU > [mozglue-static 0.1.0] > [mozglue-static 0.1.0] > [mozglue-static 0.1.0] error occurred: Command > "/usr/bin/arm-linux-gnueabihf-g++" "-O2" "-ffunction-sections" > "-fdata-sections" "-fPIC" "-march=armv7-a" > "-I/build/mozjs78-78.15.0/debian/build/dist/system_wrappers" > "-include" "/build/mozjs78-78.15.0/config/gcc_hidden.h" > "-U_FORTIFY_SOURCE" "-D_FORTIFY_SOURCE=2" "-fstack-protector-strong" > "-DNDEBUG=1" "-DTRIMMED=1" "-DEXPORT_JS_API" "-DMOZ_HAS_MOZGLUE" > "-I/build/mozjs78-78.15.0/js/src/rust" > "-I/build/mozjs78-78.15.0/debian/build/js/src/rust" > "-I/build/mozjs78-78.15.0/debian/build/dist/include" "-fPIC" > "-DMOZILLA_CLIENT" > "-include" "/build/mozjs78-78.15.0/debian/build/js/src/js-confdefs.h" > "-Wdate-time" "-D_FORTIFY_SOURCE=2" "-Wall" "-Wempty-body" > "-Wignored-qualifiers" "-Woverloaded-virtual" "-Wpointer-arith" > "-Wsign-compare" "-Wtype-limits" "-Wunreachable-code" "-Wwrite-strings" > "-Wno-invalid-offsetof" "-Wc++2a-compat" "-Wduplicated-cond" > "-Wimplicit-fallthrough" "-Wunused-function" "-Wunused-variable" > "-Wno-error=maybe-uninitialized" "-Wno-error=deprecated-declarations" > "-Wno-error=array-bounds" "-Wno-error=coverage-mismatch" > "-Wno-error=free-nonheap-object" "-Wno-multistatement-macros" > "-Wno-error=class-memaccess" "-Wno-error=deprecated-copy" "-Wformat" > "-Wformat-overflow=2" "-Wno-noexcept-type" "-fno-sized-deallocation" > "-fno-aligned-new" "-g" "-O2" "-ffile-prefix-map=/build/mozjs78-78.15.0=." > "-fstack-protector-strong" "-Wformat" "-Werror=format-security" "-fno-rtti" > "-ffunction-sections" "-fdata-sections" "-fno-exceptions" "-fno-math-errno" > "-pthread" "-pipe" "-g" "-freorder-blocks" "-O3" "-fomit-frame-pointer" > "-funwind-tables" "-DMOZILLA_CONFIG_H" > "-I" "/build/mozjs78-78.15.0/debian/build/js/src" > "-I" "/build/mozjs78-78.15.0/debian/build/dist/include" > "-DMOZ_HAS_MOZGLUE" "-o" > "/build/mozjs78-78.15.0/debian/build/armv7-unknown-linux-gnueabihf/release/build/mozglue-static-9450b28414dcb4fc/out/wrappers.o" > "-c" "wrappers.cpp" > with args "arm-linux-gnueabihf-g++" did not execute successfully (status > code exit code: 1). At a guess, perhaps the problem is that the mozjs build system is explicitly specifying -march=armv7-a when it should be something like -march=armv7-a+vfpv3 or accepting the compiler's default? smcv
