You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 21, 2019. It is now read-only.
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.
0 commit comments