LLVM has crashes at some `half` operations when built with assertions
enabled if fp-armv8 is not available [1]. Things seem to usually work,
but we are reaching LLVM undefined behavior so this needs to be
disabled.
[1]: https://github.com/llvm/llvm-project/issues/129394
With the `compiler-builtins` update to 0.1.137 [1], we now provide
symbols necessary to work with `f128` everywhere. This means that we are
no longer restricted to 64-bit linux, and can enable tests by default.
There are still a handful of platforms that need to remain disabled
because of bugs. This patch additionally disables the following:
1. MIPS [2]
2. 32-bit x86 [3]
Math support is still off by default since those symbols are not yet
available.
[1]: https://github.com/rust-lang/rust/pull/132433
[2]: https://github.com/llvm/llvm-project/issues/96432
[3]: https://github.com/llvm/llvm-project/issues/77401
There is a MinGW ABI bug that prevents `f16` and `f128` from being
usable on `windows-gnu` targets. This does not affect MSVC; however, we
have `f16` and `f128` tests disabled on all Windows targets.
Update the gating to only affect `windows-gnu`, which means `f16` tests
will be enabled. There is no effect for `f128` since the default
fallback is `false`.
These were disabled because Apple uses a special ABI for `f16`.
`compiler-builtins` merged a fix for this in [1], which has since
propagated to rust-lang/rust. Enable tests since there should be no
remaining issues on these platforms.
[1]: https://github.com/rust-lang/compiler-builtins/pull/675
The only requirement for `f16` support, aside from LLVM not crashing and
no ABI issues, is that symbols to convert to and from `f32` are
available. Since the update to compiler-builtins in [1], we now provide
these on all platforms.
This also enables `f16` math since there are no further requirements.
Still excluded are platforms for which LLVM emits infinitely-recursing
code.
[1]: https://github.com/rust-lang/rust/pull/125016
This adds missing functions for math operations on the new float types.
Platform support is pretty spotty at this point, since even platforms
with generally good support can be missing math functions.
`std/build.rs` is updated to reflect this.
To avoid this linker error:
$ sudo apt install libc6-mips-cross gcc-mips-linux-gnu
$ CC_mips_unknown_linux_gnu=mips-linux-gnu-gcc \
CARGO_TARGET_MIPS_UNKNOWN_LINUX_GNU_LINKER=mips-linux-gnu-gcc \
./x test library/std --target mips-unknown-linux-gnu
undefined reference to `__gnu_f2h_ieee'
You get the same linker error also with mipsel, mips64 and
mips64el toolchains.
The target_arch of `powerpc64le` is `powerpc64`, so
`powerpc64le` can be removed from a match arm in build.rs
related to f16.
You can check available `target_arch`:s with:
$ rustc +nightly -Zunstable-options --print all-target-specs-json \
| grep powerpc | grep arch | sort | uniq
"arch": "powerpc",
"arch": "powerpc64",
There are some complexities about what platforms we can test f16 and
f128 on. Put this in build.rs so we have an easy way to configure tests
with a single attribute, and keep it up to date.
Introducing a new config for this purpose as NetBSD 9 or 8 will be still around
for a good while. For now, we re finally enabling sys::unix::rand::getrandom.
Currently, when building with `build-std`, some library build scripts
check properties of the target by inspecting the target triple at
`env::TARGET`, which is simply set to the filename of the JSON file
when using JSON target files.
This patch alters these build scripts to use `env::CARGO_CFG_*` to
fetch target information instead, allowing JSON target files
describing platforms without `restricted_std` to build correctly when
using `-Z build-std`.
Fixes wg-cargo-std-aware/#60.
Co-authored-by: Frank Laub <flaub@risc0.com>
Co-authored-by: nils <nils@risc0.com>
Co-authored-by: Victor Graf <victor@risczero.com>
Co-authored-by: weikengchen <w.k@berkeley.edu>
It might happen that a synthetic target name does not match one of the
hardcoded ones in std's build script, causing std to fail to build. This
commit changes the std build script avoid including the restricted-std
feature unconditionally when a synthetic target is being built.
This commit goes through and updates various `#[cfg]` as appropriate to
get the wasm64-unknown-unknown target behaving similarly to the
wasm32-unknown-unknown target. Most of this is just updating various
conditions for `target_arch = "wasm32"` to also account for `target_arch
= "wasm64"` where appropriate. This commit also lists `wasm64` as an
allow-listed architecture to not have the `restricted_std` feature
enabled, enabling experimentation with `-Z build-std` externally.
The main goal of this commit is to enable playing around with
`wasm64-unknown-unknown` externally via `-Z build-std` in a way that's
similar to the `wasm32-unknown-unknown` target. These targets are
effectively the same and only differ in their pointer size, but wasm64
is much newer and has much less ecosystem/library support so it'll still
take time to get wasm64 fully-fledged.
SOLID[1] is an embedded development platform provided by Kyoto
Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support
for SOLID.
# New Targets
The following targets are added:
- `aarch64-kmc-solid_asp3`
- `armv7a-kmc-solid_asp3-eabi`
- `armv7a-kmc-solid_asp3-eabihf`
SOLID's target software system can be divided into two parts: an
RTOS kernel, which is responsible for threading and synchronization,
and Core Services, which provides filesystems, networking, and other
things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on
the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems
(more precisely, systems where only one processor core is allocated for
SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is
traditionally only specified at the source-code level, the ABI is
unique to each implementation, which is why `asp3` is included in the
target names.
More targets could be added later, as we support other base kernels
(there are at least three at the point of writing) and are interested
in supporting other processor architectures in the future.
# C Compiler
Although SOLID provides its own supported C/C++ build toolchain, GNU Arm
Embedded Toolchain seems to work for the purpose of building Rust.
# Unresolved Questions
A μITRON4 kernel can support `Thread::unpark` natively, but it's not
used by this commit's implementation because the underlying kernel
feature is also used to implement `Condvar`, and it's unclear whether
`std` should guarantee that parking tokens are not clobbered by other
synchronization primitives.
# Unsupported or Unimplemented Features
Most features are implemented. The following features are not
implemented due to the lack of native support:
- `fs::File::{file_attr, truncate, duplicate, set_permissions}`
- `fs::{symlink, link, canonicalize}`
- Process creation
- Command-line arguments
Backtrace generation is not really a good fit for embedded targets, so
it's intentionally left unimplemented. Unwinding is functional, however.
## Dynamic Linking
Dynamic linking is not supported. The target platform supports dynamic
linking, but enabling this in Rust causes several problems.
- The linker invocation used to build the shared object of `std` is
too long for the platform-provided linker to handle.
- A linker script with specific requirements is required for the
compiled shared object to be actually loadable.
As such, we decided to disable dynamic linking for now. Regardless, the
users can try to create shared objects by manually invoking the linker.
## Executable
Building an executable is not supported as the notion of "executable
files" isn't well-defined for these targets.
[1] https://solid.kmckk.com/SOLID/
[2] http://ertl.jp/ITRON/SPEC/mitron4-e.html
[3] https://en.wikipedia.org/wiki/ITRON_project
[4] https://toppers.jp/
