This repository has been archived by the owner on May 21, 2019. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rust: Create 3 logical ARM builds, based on support for VFP & Thumb2
The three types of `compiler-rt` builds we now support on ARM are: - `arm`: This is for targets like arm-unknown-linux-gnueabi. It assumes the target doesn't support hardware float (VFP), nor Thumb2 instructions. - `armhf`: This is for targets like arm-unknown-linux-gnueabihf (but also arm-linux-androideabi). It assumes the target supports VFP but not Thumb2 instructions. - `armv7`: This is for targets like armv7-unknown-linux-gnueabihf. It assumes the target supports both VFP and Thumb2 instructions. These three types (mostly) mirror the way Rust's ARM targets are named. The ones starting with `arm-` and ending with `eabi` fall in the `arm` bucket, the ones starting with `arm-` and ending with `eabihf` fall in the `armhf` bucket (although Android is an exception), and the ones starting with `armv7-` fall in the `armv7` bucket. This CL will have a couple of effects: - The CMake-based and plain Make-based builds would previously build different builtins for the same target triple. E.g. arm-linux-androideabi would have Thumb2 but not VFP builtins with the former, but VFP and not Thumb2 builtins with the latter. The CMake-based build is now consistent with the plain Make-based build. - The CMake-based build would *always* specific `-march=armv7-a` for any ARM build, even if it was for say, an ARMv6 target. This is now fixed and the build will use whatever CMAKE_C_FLAGS were specified during configuration instead. - The plain Make-based builds wouldn't build the ARM-specific builtins for targets triples like `arm-unknown-linux-gnueabi` before , because the `Arch` variable would get set to `arm`, which wasn't in the list of `OnlyArchs` in the `lib/builtins/arm/Makefile`. This was confusing though, because for part of the builtins (the non ARM-specific ones) we would use the `compiler-rt` implementation, while for others we would end up using the `libgcc` implementation. After this change, we'll always use the `compiler-rt` implementation. - For similar reasons, target triples like `arm-unknown-linux-musleabi` would not have the ARM-specific builtins built. For MUSL targets that is a problem though, since they won't link with `libgcc` at all, and hence the ARM-specific builtins symbols would be missing at link time. This is the reason why I started working on this change. This change will need an accompanying change in Rust's src/bootstrap/build/native.rs file to avoid breaking the Android build.
- Loading branch information