Repository navigation
Armv6 builds of rust appear to be armv7 contaminated. #49280
Description
I maintain Raspbian, a project to re-build Debian armhf for armv6. I have been trying to upgrade the rustc package in Raspbian buster from 1.23 to 1.24.
We scan all built packages with readelf to look for armv7 code that has slipped through the net and while buliding rust 1.24 I ran into a couple of files where readelf shows armv7 tags.
/usr/lib/arm-linux-gnueabihf/librustc_trans-7f6686b7daae4f4c.so
/usr/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_binaryen-70d23131694c64c7.rlib
It is possible that this is a false positive, for example the armv7 code could be hidden behind runtime checks. Unfortunately I have been unable to determine where exactly the armv7 tags are coming from (I am not an expert on rust of it's build system by any means). It is also possible that this represents a real bug that will lead to crashes on armv6.
Help determining which one it is would be much appreciated.
Activity
plugwash commentedon Mar 22, 2018
I suspect #49267 is related, different platform but a similar looking contamination issue on one of the same libraries.
plugwash commentedon Mar 22, 2018
Based on the other report I looked for a similarly named log and found
build/arm-unknown-linux-gnueabihf/stage0-rustc/arm-unknown-linux-gnueabihf/release/build/rustc_binaryen-881941f3666d29e3/output
And in there I found "-march=native"
Further searching found
ADD_COMPILE_FLAG("-march=native")
In
src/binaryen/CMakeLists.txt
I have commented that line out and will see where I get to.
As a general rule the only time -march=native is appropriate is when a user specifically specifies it because they know that the binaries they are building will only ever be used on the machine they are built on.
sanxiyn commentedon Mar 23, 2018
Since both
librustc_transandlibrustc_binaryenlink LLVM and others don't, this points LLVM build as a source of a problem.plugwash commentedon Mar 23, 2018
Removing the -march=native from src/binaryen/CMakeLists.txt seems to have resulted in a build with no armv7 contamination.
cuviper commentedon Mar 24, 2018
If binaryen was the only problem, note that it's been removed in #48125. So I guess the remaining question is whether we need to fix this on the beta branch, just for 1.25.
Also FWIW, the binaryen code will only execute if you target
wasm32-unknown-unknown.workingjubilee commentedon Jun 10, 2021
Apologies if I am mistaken, but I believe this was fixed with the removal of binaryen, so closing.