Skip to content

Tracking Issue for target modifiers #136966

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
6 of 14 tasks
Darksonn opened this issue Feb 13, 2025 · 0 comments
Open
6 of 14 tasks

Tracking Issue for target modifiers #136966

Darksonn opened this issue Feb 13, 2025 · 0 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-target_modifiers `#![feature(target_modifiers)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Darksonn
Copy link
Contributor

Darksonn commented Feb 13, 2025 •
edited
Loading

This is a tracking issue for the RFC "3716" (rust-lang/rfcs#3716).

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

Unresolved Questions

  • Details of the flag for opt-out.

Implementation history

cc @ojeda @azhogin
@Darksonn Darksonn added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Feb 13, 2025
@oli-obk oli-obk added the F-target_modifiers `#![feature(target_modifiers)]` label Feb 13, 2025
@ojeda ojeda mentioned this issue Feb 13, 2025
Open
95 tasks
@Alvenix Alvenix mentioned this issue Feb 26, 2025
Open
@Darksonn Darksonn mentioned this issue Mar 13, 2025
Open
@workingjubilee workingjubilee mentioned this issue Mar 14, 2025
Open
2 tasks
@Darksonn Darksonn mentioned this issue May 5, 2025
Merged
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 5, 2025
@GuillaumeGomez
Rollup merge of rust-lang#140661 - Darksonn:fixedx18-tm, r=wesleywiser
5b2887b 
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`.
@jieyouxu jieyouxu added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label May 5, 2025
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 5, 2025
@GuillaumeGomez
Rollup merge of rust-lang#140661 - Darksonn:fixedx18-tm, r=wesleywiser
0d7067d 
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`.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue May 6, 2025
@rust-timer
Unrolled build for rust-lang#140661
e25a70b 
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
Assignees
No one assigned
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-target_modifiers `#![feature(target_modifiers)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@oli-obk @Darksonn @jieyouxu