Like SGX, Xous does not have any libc to link against. As a result,
memory intrinsics need to be available as part of `compiler_builtins`
Signed-off-by: Sean Cross <sean@xobs.io>
This has a very long history, summarized in
https://github.com/rust-lang/rust/issues/109064. This port is a very
minimal subset of `aarch64/lse.S` from LLVM's compiler-rt. In
particular, it is missing the following:
1. Any form of runtime dispatch between LL/SC and LSE.
Determining which version of the intrinsics to use
requires one of the following:
i) `getauxval` from glibc. It's unclear whether `compiler_builtins` is
allowed to depend on libc at all, and musl doesn't even support
getauxval. Don't enshrine the requirement "de-facto" by making it
required for outline-atomics.
ii) kernel support. Linux and FreeBSD have limited support, but it
requires an extremely recent kernel version and doesn't work at all under QEMU (https://github.com/rust-lang/rust/issues/109064#issuecomment-1494939904).
Instead, we hard-code LL/SC intrinsics. Users who want LSE support
should use the LLVM compiler-rt (if you're building from source in
rust-lang/rust, make sure you have `src/llvm-project` checked out
locally. the goal is to soon add a new `optimized-compiler-builtins`
option so this is easier to discover).
2. The global `___aarch64_have_lse_atomics` CTOR, required to do runtime
dispatch. Thom Chiviolani has this to say about global CTORs:
> static ctors are problems because we are pretty eager about dead code elim
> in general if you have a module that isnt directly reference we will probably not have its static ctors
> also, while llvm has a super robust way to have a static ctor (theres s special "appending global" to use for c++), we dont use that and just have people make a #[used] static in a special section
> 1. the robust way kinda requires rust knowing that the argument is a static ctor (maybe a #[rustc_static_ctor] attribute). it also would be... finnicky, since on windows we actually care beyond being a static ctor, that we run as part in a specific group of ctors, which means a very specific section (one for TLS and the other for, uh, i dont remember)
> 2. we still actually have to codegen the cgu that isn't referenced. but maybe we could remember that it has that attribute and use that
So while this is possible in theory, it's decidedly non-trivial, and
needs invasive changes to rust itself. In any case, it doesn't matter
until we decide the story around libc.
3. The 16-byte (i128) version of compare_and_swap. This wouldn't be
*too* hard to add, but it would be hard to test. The way I tested the
existing code was not just with unit tests but also by loading it as a
path dependency and running `x test core` - the latter caught several
bugs the unit tests didn't catch (because I originally wrote the tests
wrong). So I am slightly nervous about adding a 16-byte version that is
much more poorly tested than the other intrinsics.
int_util.c includes stdlib.h if `_WIN32` is defined. When compiling
the UEFI targets with clang they are treated as Windows targets (e.g. if
the Rust target is x86_64-unknown-uefi, the clang target is
x86_64-unknown-windows-gnu). So stdlib.h gets included, even though we
are compilling with `-ffreestanding` and don't want stdlib.h to be
used. That file may not be present, or an incompatible version might be
installed leading to typedef redefinition errors.
The contents of stdlib.h aren't actually needed for these targets anyway
(due to `__STDC_HOSTED__` being 0), so create a minimal stdlib.h in
`build.rs` when `target_os == uefi` and add it to the include path.
The UEFI targets link with `/SAFESEH`. That requires that objects have a
symbol called [`@feat.00`]. Clang adds that symbol for COFF targets if
the input is a C file, but not if the input is an ASM file. That doesn't
prevent compiler_builtins or rustc from building, but using the
resulting rustc to compile something that references one of the objects
lacking `@feat.00` will result in a linker error.
Fix by removing all the `.S` implementations when `target_os == uefi`.
[`@feat.00`]: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-sxdata-section
The "xous" operating system is enturely Rust-based, meaning it has no
libc. Therefore, it relies on `compiler-builtins` for all intrinsics.
Unfortunately, there are not yet Rust equivalents for all C functions.
For example, triganometric functions are still missing. In the meantime,
enable C replacements for these functions so that Rust programs compiled
for Xous can call these functions.
Signed-off-by: Sean Cross <sean@xobs.io>
According to the README this file isn't used by rust, but it's currently
included which leads to these linker warnings in some cases:
```
ld: warning: linker symbol '$ld$hide$os10.5$___udivti3' hides a non-existent symbol '___udivti3'
ld: warning: linker symbol '$ld$hide$os10.4$___umoddi3' hides a non-existent symbol '___umoddi3'
ld: warning: linker symbol '$ld$hide$os10.5$___umoddi3' hides a non-existent symbol '___umoddi3'
ld: warning: linker symbol '$ld$hide$os10.4$___umodti3' hides a non-existent symbol '___umodti3'
ld: warning: linker symbol '$ld$hide$os10.5$___umodti3' hides a non-existent symbol '___umodti3'
```
This file exclusively contains macros which hides old symbols on Apple
OS versions where they don't exist.
fc10370ef7/compiler-rt/lib/builtins/apple_versioning.c
The change in 186517b3266a7bb2b2310927f7342ea7f41790c3 was intended to
affect only `arm-linux-androideabi` but also affected
`armv7-linux-androideabi` which is not a pre-ARMv6 architecture.
Fixes#449
The msvc toolchain does not support building `.s` files, clang only
supports generating out-of-line atomics on Linux and gcc does not
support aarch64 for Windows at all. Therefore, we don't need to compile
`lse.s` on `aarch64-pc-windows-msvc`.
llvm/llvm-project@a4ac434c47 saw the
addition of out-of-line aarch64 atomic intrinsics. LLVM will sometimes
emit these, so we need to ensure they're included in Rust's compiler-rt.
`AArch64` GCCs exit with an error condition when they encounter any kind of
floating point code if the `nofp` and/or `nosimd` compiler flags have been set.
Therefore, evaluate if those flags are present and set a boolean that causes any
compiler-rt intrinsics that contain floating point source to be excluded for
this target.
This patch prepares https://github.com/rust-lang/rust/pull/68334
This commit removes the `compiler-rt` submodule from this repository.
The goal here is to align the `compiler-rt` used for compiling C
intrinsics with the upstream rust-lang/rust's usage of `llvm-project`.
Currently we have both an `llvm-project` repository as well as
`compiler-rt`, but they can naturally get out of sync and it's just one
more submodule to manage.
The thinking here is that the feature `c` for this crate, when
activated, will require the user to configure where the source code for
`compiler-rt` is present. This places the onus on the builder of
`compiler-builtins` to check-out and arrange for the appropriate
`compiler-rt` source code to be placed somewhere. For rust-lang/rust
this is already done with the `llvm-project` submodule, and we can
arrange for it to happen on this crate's CI anyway.
For users of this crate this is a bit of a bummer, but `c` is disabled
by default anyway and it seems unlikely that `c` is explicitly opted in
to all that much. (given the purpose of this crate)
This should allow us to archive the `compiler-rt` repository and simply
use `llvm-project` in the rust-lang/rust repository.
This commit tweaks the implementation of the synthetic
`#[use_c_shim_if]` attribute, renaming it to
`#[maybe_use_optimized_c_shim]` in the process. This no longer requires
specifying a `#[cfg]` clause indicating when the optimized intrinsic
should be used, but rather this is inferred and printed from the build
script.
The build script will now print out appropriate `#[cfg]` directives for
rustc to indicate what intrinsics it's compiling. This should remove the
need for us to keep the build script and the source in sync, but rather
the build script can simply take care of everything.
