| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Enable xgot feature for mips64 musl targets
This was missed in b65c2afdfd9aaee977302516c9ef177861abfe74, which only enabled it for the glibc targets.
I didn't feel comfortable touching the OpenWRT target, whoever maintains that will probably want to take a look whether it is necessary there as well.
|
|
This stabilizes a subset of the `-Clinker-features` components on x64 linux:
the lld opt-out.
The opt-in is not stabilized, as interactions with other stable flags require
more internal work, but are not needed for stabilizing using rust-lld by default.
Similarly, since we only switch to rust-lld on x64 linux, the opt-out is
only stabilized there. Other targets still require `-Zunstable-options`
to use it.
|
|
default data address space
|
|
This was missed in b65c2afdfd9aaee977302516c9ef177861abfe74, which only
enabled it for the glibc targets.
I didn't feel comfortable touching the OpenWRT target, whoever maintains
that will probably want to take a look whether it is necessary there as
well.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Expose elf abi on ppc64 targets
Fixes https://github.com/rust-lang/rust/issues/60617 (after MCP https://github.com/rust-lang/compiler-team/issues/885 is accepted) by exposing the abi information on ppc64 targets.
Conditional compilation can now use `cfg(target_abi = "elfv1")` or `cfg(target_abi = "elfv2")` to determine the abi in use.
Technical details are included in the other PR https://github.com/rust-lang/rust/pull/142598
|
|
Convert some ABI tests to use `extern "rust-invalid"`
|
|
|
|
|
|
|
|
rustc_target: document public AbiMap-related fn and variants
|
|
|
|
|
|
workingjubilee:redescribe-rustc_target-more-accurately, r=wesleywiser
Refresh module-level docs for `rustc_target::spec`
We have long since gone on a curveball from the flexible-target-specification RFC by introducing stability and soundness promises to the language and compiler which we often struggle with extending to target-specific implementation details. Indeed, we often *literally cannot*. We also have modified the search algorithm details. Update the comments for `rustc_target::spec` considerably.
|
|
|
|
|
|
|
|
|
|
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
|
|
|
|
|
|
|
|
r=workingjubilee
Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions
This adds back the `unsupported_calling_conventions` lint that was removed in https://github.com/rust-lang/rust/pull/129935, in order to start the process of dealing with https://github.com/rust-lang/rust/issues/137018. Specifically, we are going for the plan laid out [here](https://github.com/rust-lang/rust/issues/137018#issuecomment-2672118326):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64
The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various
|
|
store `target.min_global_align` as an `Align`
Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
|
|
compiler: Add track_caller to AbiMapping::unwrap
Same reason as it is on Option's.
|
|
Add new Tier-3 targets: `loongarch32-unknown-none*`
MCP: https://github.com/rust-lang/compiler-team/issues/865
NOTE: LoongArch32 ELF object support is available starting with object v0.37.0.
|
|
calling conventions
|
|
|
|
workingjubilee:apple-likes-frame-pointers-but-not-that-much, r=madsmtm
compiler: set Apple frame pointers by architecture
All Apple targets stop overriding this configuration and instead use the default base of FramePointer::NonLeaf, which means some Apples will have less frame pointers in leaf functions.
r? ``@madsmtm``
cc ``@thomcc``
|
|
Apple targets can now overriding this configuration and instead use the
default based on their architecture, which means aarch64 targets now
have less frame pointers in leaf functions.
|
|
Same reason as it is on Option's.
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/865
|
|
Replace ad-hoc ABI "adjustments" with an `AbiMap` to `CanonAbi`
Our `conv_from_spec_abi`, `adjust_abi`, and `is_abi_supported` combine to give us a very confusing way of reasoning about what _actual_ calling convention we want to lower our code to and whether we want to compile the resulting code at all. Instead of leaving this code as a miniature adventure game in which someone tries to combine stateful mutations into a Rube Goldberg machine that will let them escape the maze and arrive at the promised land of codegen, we let `AbiMap` devour this complexity. Once you have an `AbiMap`, you can answer which `ExternAbi`s will lower to what `CanonAbi`s (and whether they will lower at all).
Removed:
- `conv_from_spec_abi` replaced by `AbiMap::canonize_abi`
- `adjust_abi` replaced by same
- `Conv::PreserveAll` as unused
- `Conv::Cold` as unused
- `enum Conv` replaced by `enum CanonAbi`
target-spec.json changes:
- If you have a target-spec.json then now your "entry-abi" key will be specified in terms of one of the `"{abi}"` strings Rust recognizes, e.g.
```json
"entry-abi": "C",
"entry-abi": "win64",
"entry-abi": "aapcs",
```
|
|
`adjust_abi` is not needed and `is_abi_supported` can be a 1-liner.
|
|
makes entry_abi a lowering of the ABI string, so now it can be
```json
"entry_abi": "C",
"entry_abi": "win64",
"entry_abi": "aapcs",
```
|
|
- Add AbiMapping for encoding the nuance of deprecated ABIs
|
|
|
|
|
|
* https://maskray.me/blog/2023-06-18-port-llvm-xray-to-apple-systems
* https://github.com/llvm/llvm-project/blob/llvmorg-20.1.4/clang/lib/Driver/XRayArgs.cpp#L31
|
|
workingjubilee:aarch64-linux-should-use-frame-pointers, r=compiler-errors
aarch64-linux: Default to FramePointer::NonLeaf
For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements:
- Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers
- Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
- AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer
Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets also use non-leaf frame pointers. This reflects what compilers like clang do.
|
|
[win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test
PR #140758 added the undocumented `/arm64hazardfree` MSVC linker flag to work around a test failure where LLVM generated code that would trip a hazard in an outdated ARM processor.
Adding this flag caused issues with LLD, as it doesn't recognize it.
Rethinking the issue, using the undocumented flag seems like the incorrect solution: there's no guarantee that the flag won't be removed in the future, or change its meaning.
Instead, I've disabled the problematic test for Arm64 Windows and have filed a bug with the MSVC team to have the check removed: <https://developercommunity.microsoft.com/t/Remove-checking-for-and-fixing-Cortex-A/10905134>
This PR supersedes #140977
r? ```@jieyouxu```
|
|
For aarch64-apple and aarch64-windows, platform docs state that code
must use frame pointers correctly. This is because the AAPCS64 mandates
that a platform specify its frame pointer conformance requirements:
- Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers
- Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
- AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer
Unwinding code either requires unwind tables or frame pointers, and
on aarch64 the expectation is that one can use frame pointers for this.
Most Linux targets represent a motley variety of possible distributions,
so it is unclear who to defer to on conformance, other than perhaps Arm.
In the absence of a specific edict for a given aarch64-linux target,
Rust will assume aarch64-linux targets use non-leaf frame pointers.
This reflects what compilers like clang do.
|
|
disable problematic test
|
|
Unfortunately, multiple people are reporting linker warnings related to
`__rust_no_alloc_shim_is_unstable` after this change. The solution isn't
quite clear yet, let's revert to green for now, and try a reland with a
determined solution for `__rust_no_alloc_shim_is_unstable`.
This reverts commit c8b7f32434c0306db5c1b974ee43443746098a92, reversing
changes made to 667247db71ea18c4130dd018d060e7f09d589490.
|
|
|
|
Enable non-leaf Frame Pointers for Arm64 Windows
Microsoft recommends enabling frame pointers for Arm64 Windows as it enables fast stack walking, from <https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers>:
> The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack.
I'm setting this to "non-leaf" as leaf functions shouldn't be spilling registers and so won't touch the frame pointer.
|
|
Fix linking statics on Arm64EC
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
CI found another bug: we only apply `DllImport` to non-local statics that aren't foreign items (i.e., in an `extern` block), that is we want to use `DllImport` for statics coming from other Rust crates. However, `__rust_no_alloc_shim_is_unstable` is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an `extern "Rust"` block, thus they do not apply `DllImport` to it and so fails to link if it is exported by the previous crate as `DATA`. The fix is to apply `DllImport` to foreign items that are marked with the `rustc_std_internal_symbol` attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).
Fixes #138541
---
try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
|
|
|
|
|
|
|
