Docker file arm fpu setting

[paulwratt]

in the following line what does -d16 refer to, or enable:

ENV CFLAGS_armv7_unknown_linux_musleabihf='-mfpu=vfpv3-d16'

As far as I understand this is device specific, that is -mfpu=vfpv3 will apply to more (Broadcom?) armv7 devices that have a vfpv3

[messense]

See https://wiki.debian.org/ArmHardFloatPort/VfpComparison#FPU

VFPv3-D16 is the common denominator of the processors to support here (therefore the recommended build option is -mfpu=vfpv3-d16)

[messense]

rustc uses vfp3-d32, perhaps we should use that as well.

$ rustc +nightly --print target-spec-json -Zunstable-options --target armv7-unknown-linux-musleabihf
{
  "abi": "eabihf",
  "arch": "arm",
  "crt-objects-fallback": "musl",
  "crt-static-default": true,
  "crt-static-respected": true,
  "data-layout": "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64",
  "dynamic-linking": true,
  "env": "musl",
  "features": "+v7,+vfp3,-d32,+thumb2,-neon",
  "has-rpath": true,
  "has-thread-local": true,
  "is-builtin": true,
  "llvm-target": "armv7-unknown-linux-gnueabihf",
  "max-atomic-width": 64,
  "os": "linux",
  "position-independent-executables": true,
  "post-link-objects-fallback": {
    "dynamic-dylib": [
      "crtendS.o",
      "crtn.o"
    ],
    "dynamic-nopic-exe": [
      "crtend.o",
      "crtn.o"
    ],
    "dynamic-pic-exe": [
      "crtendS.o",
      "crtn.o"
    ],
    "static-dylib": [
      "crtendS.o",
      "crtn.o"
    ],
    "static-nopic-exe": [
      "crtend.o",
      "crtn.o"
    ],
    "static-pic-exe": [
      "crtendS.o",
      "crtn.o"
    ]
  },
  "pre-link-objects-fallback": {
    "dynamic-dylib": [
      "crti.o",
      "crtbeginS.o"
    ],
    "dynamic-nopic-exe": [
      "crt1.o",
      "crti.o",
      "crtbegin.o"
    ],
    "dynamic-pic-exe": [
      "Scrt1.o",
      "crti.o",
      "crtbeginS.o"
    ],
    "static-dylib": [
      "crti.o",
      "crtbeginS.o"
    ],
    "static-nopic-exe": [
      "crt1.o",
      "crti.o",
      "crtbegin.o"
    ],
    "static-pic-exe": [
      "rcrt1.o",
      "crti.o",
      "crtbeginS.o"
    ]
  },
  "relro-level": "full",
  "supported-split-debuginfo": [
    "packed",
    "unpacked",
    "off"
  ],
  "target-family": [
    "unix"
  ],
  "target-mcount": "\u0001mcount",
  "target-pointer-width": "32"
}

[paulwratt]

Ok, but you should test it on a RPi too, as I have never seen it there or used it there (I did some research when the RPi3 came out while trying to compile RetroArch, before they released a RPi3 version - ie I dont think it will work on the older RPi2 boards)

There was recently a similar issue with options on WolfSSL using specific neon settings. They initially started with armv7 settings that exclude non-RPi devices.

[paulwratt]

it might be that even vfp is enough, it depends on how the compile handles it. That link implied that D32 was the default (but the Marvel and the Terga didn't have that option). I think it might be more the case of "the chip defaults to whatever the hardware has" - are you able to test it on device(s) that are different? (Does every vfpv3 and a working -d16?)

[messense]

are you able to test it on device(s) that are different?

No, I only have a RPi4.

I think it might be better to align with whatever rustc defaults to? A mismatch between gcc and rustc may also cause trouble. And user can always override that env var when building.

[paulwratt]

No, I only have a RPi4.

actually you should be able to test the -d16 option on that. I should "do something different" if its not valid? (or do the math slower than the default)

EDIT:

A mismatch between gcc and rustc may also cause trouble

thanks for making that known. That might be because rustup.sh compiles rustc with the local compiler.

[messense]

actually you should be able to test the -d16 option on that.

Do you have a list of steps to do the test? I'm not total sure how.

I should "do something different" if its not valid?

Sorry, what do you mean?

And user can always override that env var when building.

To clarify, docker run --rm -it -v "$(pwd)":/home/rust/src --env CFLAGS_armv7_unknown_linux_musleabihf='-mfpu=vfpv3-d32' messense/rust-musl-cross:armv7-musleabihf should do.

[paulwratt]

NOTE: If no one is complaining or a having problems then it is probably OK. I just brought it up because I have never seen or used it, and I have a few RPi's

EDIT:

I should "do something different" if its not valid?

Sorry, what do you mean?

The compiler might reject it, the program might crash, or the maths might slow down.

Sorry I dont have test case either, but I will keep that in the back of my mind and produce something later on, it might warrent further investigation, or "timing" at least - but see the first line in this post.

And atm I dont have a Tegra to check it with either. Tho I am getting some more different hardware soon, I'll look into it more then ..