rust-musl-cross
rust-musl-cross copied to clipboard
Docker file arm fpu setting
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
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
)
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"
}
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.
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
?)
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.
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.
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.
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 ..