Make -Zfixed-x18 into a target modifier
#140661
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
rustbot
added
S-waiting-on-review
14 tasks
|
@rustbot label F-target_modifiers |
95 tasks
wesleywiser
approved these changes
May 5, 2025
bors
added
S-waiting-on-bors
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
May 5, 2025
Make `-Zfixed-x18` into a target modifier As part of rust-lang#136966, the `-Zfixed-x18` flag should be turned into a target modifier. This is a blocker to stabilization of the flag. The flag was originally added in rust-lang#124655 and the MCP for its addition is [MCP#748](rust-lang/compiler-team#748). On some aarch64 targets, the x18 register is used as a temporary caller-saved register by default. When the `-Zfixed-x18` flag is passed, this is turned off so that the compiler doesn't use the x18 register. This allows end-users to use the x18 register for other purposes. For example, by accessing it with inline asm you can use the register as a very efficient thread-local variable. Another common use-case is to store the stack pointer needed by the shadow-call-stack sanitizer. There are also some aarch64 targets where not using x18 is the default – in those cases the flag is a no-op. Note that this flag does not *on its own* cause an ABI mismatch. What actually causes an ABI mismatch is when you have different compilation units that *disagree* on what it should be used for. But having a CU that uses it and another CU that doesn't normally isn't enough to trigger an ABI problem. However, we still consider the flag to be a target modifier in all cases, since it is assumed that you are passing the flag because you intend to assign some other meaning to the register. Rejecting all flag mismatches even if not all are unsound is consistent with [RFC#3716](https://rust-lang.github.io/rfcs/3716-target-modifiers.html). See the headings "not all mismatches are unsound" and "cases that are not caught" for additional discussion of this. On aarch64 targets where `-Zfixed-x18` is not a no-op, it is an error to pass `-Zsanitizer=shadow-call-stack` without also passing `-Zfixed-x18`.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 5, 2025
…llaumeGomez Rollup of 11 pull requests Successful merges: - rust-lang#139764 (Consistent trait bounds for ExtractIf Debug impls) - rust-lang#140035 (Implement RFC 3503: frontmatters) - rust-lang#140080 (mir-opt: Use one MirPatch in MatchBranchSimplification) - rust-lang#140115 (mir-opt: execute MatchBranchSimplification after GVN) - rust-lang#140357 (bypass linker configuration and cross target check on `x check`) - rust-lang#140374 (Resolve instance for SymFn in global/naked asm) - rust-lang#140393 (std: get rid of `sys_common::process`) - rust-lang#140532 (Fix RustAnalyzer discovery of rustc's `stable_mir` crate) - rust-lang#140559 (Removing rustc_type_ir in the rustc_infer codebase) - rust-lang#140636 (implement `PanicTracker` to track `t` panics) - rust-lang#140661 (Make `-Zfixed-x18` into a target modifier) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 5, 2025
…llaumeGomez Rollup of 11 pull requests Successful merges: - rust-lang#140080 (mir-opt: Use one MirPatch in MatchBranchSimplification) - rust-lang#140115 (mir-opt: execute MatchBranchSimplification after GVN) - rust-lang#140357 (bypass linker configuration and cross target check on `x check`) - rust-lang#140374 (Resolve instance for SymFn in global/naked asm) - rust-lang#140559 (Removing rustc_type_ir in the rustc_infer codebase) - rust-lang#140605 (`fn check_opaque_type_parameter_valid` defer error) - rust-lang#140636 (implement `PanicTracker` to track `t` panics) - rust-lang#140661 (Make `-Zfixed-x18` into a target modifier) - rust-lang#140670 (calculate step duration in a panic-safe way) - rust-lang#140672 (Deeply normalize in the new solver in WF) - rust-lang#140676 (Update books) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 6, 2025
Rollup merge of rust-lang#140661 - Darksonn:fixedx18-tm, r=wesleywiser Make `-Zfixed-x18` into a target modifier As part of rust-lang#136966, the `-Zfixed-x18` flag should be turned into a target modifier. This is a blocker to stabilization of the flag. The flag was originally added in rust-lang#124655 and the MCP for its addition is [MCP#748](rust-lang/compiler-team#748). On some aarch64 targets, the x18 register is used as a temporary caller-saved register by default. When the `-Zfixed-x18` flag is passed, this is turned off so that the compiler doesn't use the x18 register. This allows end-users to use the x18 register for other purposes. For example, by accessing it with inline asm you can use the register as a very efficient thread-local variable. Another common use-case is to store the stack pointer needed by the shadow-call-stack sanitizer. There are also some aarch64 targets where not using x18 is the default – in those cases the flag is a no-op. Note that this flag does not *on its own* cause an ABI mismatch. What actually causes an ABI mismatch is when you have different compilation units that *disagree* on what it should be used for. But having a CU that uses it and another CU that doesn't normally isn't enough to trigger an ABI problem. However, we still consider the flag to be a target modifier in all cases, since it is assumed that you are passing the flag because you intend to assign some other meaning to the register. Rejecting all flag mismatches even if not all are unsound is consistent with [RFC#3716](https://rust-lang.github.io/rfcs/3716-target-modifiers.html). See the headings "not all mismatches are unsound" and "cases that are not caught" for additional discussion of this. On aarch64 targets where `-Zfixed-x18` is not a no-op, it is an error to pass `-Zsanitizer=shadow-call-stack` without also passing `-Zfixed-x18`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As part of #136966, the
-Zfixed-x18flag should be turned into a target modifier. This is a blocker to stabilization of the flag. The flag was originally added in #124655 and the MCP for its addition is MCP#748.On some aarch64 targets, the x18 register is used as a temporary caller-saved register by default. When the
-Zfixed-x18flag is passed, this is turned off so that the compiler doesn't use the x18 register. This allows end-users to use the x18 register for other purposes. For example, by accessing it with inline asm you can use the register as a very efficient thread-local variable. Another common use-case is to store the stack pointer needed by the shadow-call-stack sanitizer. There are also some aarch64 targets where not using x18 is the default – in those cases the flag is a no-op.Note that this flag does not on its own cause an ABI mismatch. What actually causes an ABI mismatch is when you have different compilation units that disagree on what it should be used for. But having a CU that uses it and another CU that doesn't normally isn't enough to trigger an ABI problem. However, we still consider the flag to be a target modifier in all cases, since it is assumed that you are passing the flag because you intend to assign some other meaning to the register. Rejecting all flag mismatches even if not all are unsound is consistent with RFC#3716. See the headings "not all mismatches are unsound" and "cases that are not caught" for additional discussion of this.
On aarch64 targets where
-Zfixed-x18is not a no-op, it is an error to pass-Zsanitizer=shadow-call-stackwithout also passing-Zfixed-x18.