Armv6 builds of rust appear to be armv7 contaminated.

[plugwash]

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.

[plugwash]

I suspect #49267 is related, different platform but a similar looking contamination issue on one of the same libraries.

[plugwash]

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]

Since both librustc_trans and librustc_binaryen link LLVM and others don't, this points LLVM build as a source of a problem.

[plugwash]

Removing the -march=native from src/binaryen/CMakeLists.txt seems to have resulted in a build with no armv7 contamination.

[cuviper]

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]

Apologies if I am mistaken, but I believe this was fixed with the removal of binaryen, so closing.