newlib is missing hardware floating support

[matthewbauer]

How can I use this newly packaged newlib with hardware floating point support?

I have the following code example:

# The commit right before your removed gcc-arm-embedded: c327df544ae0875ce71b0a82ae7a650a8e34a268
with import (fetchTarball "https://github.com/nixos/nixpkgs/archive/aa4707fc3449192b961bfd2dfc16b9042df0d7f3.tar.gz") {};
rec {
  # This is a small c file which uses `log` from libm
  file = writeTextFile {
    name = "file.c";
    text = ''
      #include <math.h>
      int _exit(int i){};  # missing symbol during build, this can be ignored.
      int main()
      {
        float v = log(0.f);
        return 0;
      }
    '';
  };

  # my build command ligne, note the -mfloat-abi=hard
  cmd = ''arm-none-eabi-gcc -mfloat-abi=hard ${file} -o file -lm -o $out'';

  # a generic buider
  build = compiler : runCommand "foo" {
    allowSubstitutes = false;
    nativeBuildInputs = [compiler];
  }
  ''arm-none-eabi-gcc -mfloat-abi=hard ${file} -o file -lm -o $out'';

  # that one success
  success = build gcc-arm-embedded;
  # that one fails, with /nix/store/z6pvjan22wqxcg787kyw89jl64dhh2ks-arm-none-eabi-binutils-2.30/bin/arm-none-eabi-ld: error: /build/ccDue1Qh.o uses VFP register arguments, /nix/store/nwf9pkcgjlcympb2yfqwx2svim6w6sa9-foo does not
  failure = build pkgsCross.arm-embedded.buildPackages.gcc;
}

Please not the -mfloat-abi=hard flag. Apparently, by default, newlib is built without hardware floating point support. See https://sourceware.org/newlib/faq.html#q4 which discuss the build flag --newlib-hw-fp:

The newlib-hw-fp option causes the library to use a set of math routines that use floating-point algorithms. By default, the newlib library math routines use integer-based algorithms to perform the desired functionality. For a platform that has fast floating-point support, the floating-point algorithms may be faster and smaller.

I'v tried to override newlib or newlibCross without success with an overlay:

 newlibCross = super.newlibCross.overrideAttrs (old : {
    configureFlags = old.configureFlags ++ ["--enable-newlib-hw-fp"];
  });

And I've tried to import my cross system using import <nixpkgs> { crossSystem = { ...; float = "hard" }; } without success either.

Originally posted by @guibou in #47533 (comment)

[Ericson2314]

Use eabihf. Probably want to expose another example system for this.

[matthewbauer]

I think in this case we should support multilib here since that is what ARM does. It shouldn't be too expensive as they're pretty small runtimes. Plus this will probably fix qmk_firmware, which use mfloat-abi=hard.

https://hydra.nixos.org/job/nixpkgs/trunk/qmk_firmware.x86_64-linux

[matthewbauer]

On qmk_firmware it is especially difficult, because we will not know ahead of time whether it will need hard float. Some use it and some don't. But it's the same gcc target for both:

https://github.com/qmk/qmk_firmware/blob/239f02408e219567be060be7e65e92e888304ed0/tmk_core/arm_atsam.mk#L24

Otherwise I suppose we could get the gcc wrapper to just ignore -mfloat-abi=hard? That would be a little bit unexpected but give us some compatibility with old arm-gcc-embedded stuff.

[Ericson2314]

There's a gazillion things one would want to very for embedded besides hard/soft float. I'm sort of morally opposed to multi-lib with embedded especially (in addition to my general disdain for building libraries with compilers), because 1,2, even 10 sizes do not fit all.

[guibou]

@Ericson2314

About eabihf, what do you mean? Based on the example for arm-none-eabi, I tried a few variation of:

import <nixpkgs> {
  crossSystem = {
    config = XXX;
    libc = "newlib";
  };
};

where XXX was:

• arm-none-eabihf: nix error Target specification with 3 components is ambiguous
• arm-none-gnueabihf: same
• arm-unknown-none-eabihf: nix error Unknown ABI: eabihf
• arm-unknown-none-gnueabihf: build error:

...
checking target system type... Invalid configuration `arm-unknown-none-gnueabihf': machine `arm-unknown-none' not recognized
configure: error: /nix/store/r47p5pzx52m3n34vdgqpk5rvqgm0m24m-bash-4.4-p23/bin/bash ./config.sub arm-unknown-none-gnueabihf failed
builder for '/nix/store/317r53lkbpdfmi4v39gc4zi263py1ls8-arm-unknown-none-gnueabihf-binutils-2.30.drv' failed with exit code 1

[Ericson2314]

eabihf needs to be added to https://github.com/NixOS/nixpkgs/blob/master/lib/systems/parse.nix .

[Ericson2314]

See http://llvm.org/doxygen/classllvm_1_1Triple.html, http://llvm.org/doxygen/Triple_8h_source.html, http://llvm.org/doxygen/Triple_8cpp.html, http://llvm.org/doxygen/Triple_8cpp_source.html .

GNU config thinks "kernel-os" rather than "os-environment", which causes your arm-unknown-none-gnueabihf build error.

[Ericson2314]

--- a/config.sub
+++ b/config.sub
@@ -1507,6 +1507,8 @@ case $os in
                ;;
        none)
                ;;
+       none-eabi | none-eabihf | none-gnueabi | none-gnueabihf)
+               ;;
        *-eabi)
                ;;
        *)

makes GNU Config a bit more flexible. But the long term politics of reconciling the LLVM and GNU approach is still needed.