abi: add AddressSpace field to Primitive::Pointer
...and remove it from `PointeeInfo`, which isn't meant for this.
There are still various places (marked with FIXMEs) that assume all pointers
have the same size and alignment. Fixing this requires parsing non-default
address spaces in the data layout string (and various other changes),
which will be done in a followup.
(That is, if it's actually worth it to support multiple different pointer sizes.
There is a lot of code that would be affected by that.)
Fixes#106367
r? ``@oli-obk``
cc ``@Patryk27``
BPF: Disable atomic CAS
Enabling CAS for BPF targets (https://github.com/rust-lang/rust/pull/105708) breaks the build of core library.
The failure occurs both when building rustc for BPF targets and when
building crates for BPF targets with the current nightly.
The LLVM BPF backend does not correctly lower all `atomicrmw` operations
and crashes for unsupported ones.
Before we can enable CAS for BPF in Rust, we need to fix the LLVM BPF
backend first.
Fixes#106795
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
...and remove it from `PointeeInfo`, which isn't meant for this.
There are still various places (marked with FIXMEs) that assume all pointers
have the same size and alignment. Fixing this requires parsing non-default
address spaces in the data layout string, which will be done in a followup.
there were fixmes for this already
i am about to remove is_ptr (since callers need to properly distinguish
between pointers in different address spaces), so might as well do this
at the same time
Include sanitizers supported by LLVM on s390x (asan, lsan, msan, tsan)
in the target definition, as well as in the compiletest supported list.
Build sanitizer runtime for the target. Enable sanitizers in the CI.
Enabling CAS for BPF targets (#105708) breaks the build of core library.
The failure occurs both when building rustc for BPF targets and when
building crates for BPF targets with the current nightly.
The LLVM BPF backend does not correctly lower all `atomicrmw` operations
and crashes for unsupported ones.
Before we can enable CAS for BPF in Rust, we need to fix the LLVM BPF
backend first.
Fixes#106795
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
Accept old spelling of Fuchsia target triples
The old spelling of Fuchsia target triples was changed in #106429 to add a proper vendor. Because the old spelling is widely used, some projects may need time to migrate their uses to the new triple spelling. The old spelling may eventually be removed altogether.
r? ``@tmandry``
Because the old spelling is widely used, some projects may need time to
migrate their uses to the new triple spelling. The old spelling may
eventually be removed altogether.
Enable Shadow Call Stack for Fuchsia on AArch64
Fuchsia already uses SCS by default for C/C++ code on ARM hardware. This patch allows SCS to be used for Rust code as well.
Add vendor to Fuchsia's target triple
Historically, Rust's Fuchsia targets have been labeled x86_64-fuchsia and aarch64-fuchsia. However, they should technically contain vendor information. This CL changes Fuchsia's target triples to include the "unknown" vendor since Clang now does normalization and handles all triple spellings.
This was previously attempted in #90510, which was closed due to inactivity.
Convert all the crates that have had their diagnostic migration
completed (except save_analysis because that will be deleted soon and
apfloat because of the licensing problem).
Historically, Rust's Fuchsia targets have been labeled x86_64-fuchsia
and aarch64-fuchsia. However, they should technically contain vendor
information. This CL changes Fuchsia's target triples to include the
"unknown" vendor since Clang now does normalization and handles all
triple spellings.
This was previously attempted in #90510, which was closed due to
inactivity.
Remove the `..` from the body, only a few invocations used it and it's
inconsistent with rust syntax.
Use `;` instead of `,` between consts. As the Rust syntax gods inteded.
Add LLVM KCFI support to the Rust compiler
This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
Mangle "main" as "__main_void" on wasm32-wasi
On wasm, the age-old C trick of having a main function which can either have no arguments or argc+argv doesn't work, because wasm requires caller and callee signatures to match. WASI's current strategy is to have compilers mangle main's name to indicate which signature they're using. Rust uses the no-argument form, which should be mangled as `__main_void`.
This is needed on wasm32-wasi as of #105395.
This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to
the Rust compiler. It initially provides forward-edge control flow
protection for operating systems kernels for Rust-compiled code only by
aggregating function pointers in groups identified by their return and
parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
On wasm, the age-old C trick of having a main function which can either have
no arguments or argc+argv doesn't work, because wasm requires caller and
callee signatures to match. WASI's current strategy is to have compilers
mangle main's name to indicate which signature they're using. Rust uses the
no-argument form, which should be mangled as `__main_void`.
This is needed on wasm32-wasi as of #105395.
Stop passing -export-dynamic to wasm-ld.
-export-dynamic was a temporary hack added in the early days of the Rust wasm32 target when Rust didn't have a way to specify wasm exports in the source code. This flag causes all global symbols, and some compiler-internal symbols, to be exported, which is often more than needed.
Rust now does have a way to specify exports in the source code: `#[export_name = "..."]`.
So as the original comment suggests, -export-dynamic can now be removed, allowing users to have smaller binaries and better encapsulation in their wasm32-unknown-unknown modules.
It's possible that this change will require existing wasm32-unknown-unknown users will to add explicit `#[export_name = "..."]` directives to exporrt the symbols that their programs depend on having exported.
-export-dynamic was a temporary hack added in the early days of the Rust
wasm32 target when Rust didn't have a way to specify wasm exports in the
source code. This flag causes all global symbols, and some compiler-internal
symbols, to be exported, which is often more than needed.
Rust now does have a way to specify exports in the source code:
`#[export_name = "..."]`.
So as the original comment suggests, -export-dynamic can now be removed,
allowing users to have smaller binaries and better encapsulation in
their wasm32-unknown-unknown modules.
It's possible that this change will require existing wasm32-unknown-unknown
users will to add explicit `#[export_name = "..."]` directives to
exporrt the symbols that their programs depend on having exported.
Fix passing MACOSX_DEPLOYMENT_TARGET to the linker
I messed up in https://github.com/rust-lang/rust/pull/103929 when merging the two base files together and as a result, started ignoring `MACOSX_DEPLOYMENT_TARGET` at the linker level. This ended up being the cause of nighty builds not running on older macOS versions.
My original hope with the previous PR was that CI would have caught something like that but there were only tests checking the compiler target definitions in codegen tests. Because of how badly this sucks to break, I put together a new test via `run-make` that actually confirms the deployment target set makes it to the linker instead of just LLVM.
Closes https://github.com/rust-lang/rust/issues/104570 (for real this time)
Remove useless borrows and derefs
They are nothing more than noise.
<sub>These are not all of them, but my clippy started crashing (stack overflow), so rip :(</sub>
Improve generating Custom entry function
This commit is aimed at making compiler-generated entry functions (Basically just C `main` right now) more generic so other targets can do similar things for custom entry. This was initially implemented as part of https://github.com/rust-lang/rust/pull/100316.
Currently, this moves the entry function name and Call convention to the target spec.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
