Skip to content

Add -Zindirect-branch-cs-prefix #140740

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.

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ojeda
Copy link
Contributor

@ojeda ojeda commented May 7, 2025

Cc: @azhogin @Darksonn

This goes on top of #135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without -Zretpoline*. GCC and Clang allow it, though.

There is a FIXME for two ignores in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: #116852.
MCP: rust-lang/compiler-team#868.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 7, 2025
@ojeda ojeda force-pushed the indirect-branch-cs-prefix branch from 4422b3c to 0582d8f Compare May 7, 2025 14:07
@ojeda ojeda force-pushed the indirect-branch-cs-prefix branch from 0582d8f to b0392c5 Compare May 7, 2025 14:16
@ojeda
Copy link
Contributor Author

ojeda commented May 7, 2025

@rustbot label F-target_modifiers A-rust-for-linux

@rustbot rustbot added A-rust-for-linux Relevant for the Rust-for-Linux project F-target_modifiers `#![feature(target_modifiers)]` labels May 7, 2025
@rust-log-analyzer

This comment has been minimized.

@ojeda
Copy link
Contributor Author

ojeda commented May 7, 2025

The error is related to the base PR -- I think this one should be clean (modulo the marked ignore-*s) when that one is.

@ojeda ojeda force-pushed the indirect-branch-cs-prefix branch from b0392c5 to f395de3 Compare May 7, 2025 15:01
@rust-log-analyzer

This comment has been minimized.

@ojeda ojeda force-pushed the indirect-branch-cs-prefix branch from f395de3 to a79ff99 Compare May 7, 2025 17:15
@rust-log-analyzer

This comment has been minimized.

@ojeda ojeda force-pushed the indirect-branch-cs-prefix branch from a79ff99 to 879a3bc Compare May 8, 2025 17:09
@rustbot rustbot added the A-rustdoc-json Area: Rustdoc JSON backend label May 8, 2025
@rust-log-analyzer

This comment has been minimized.

@bors

This comment was marked as resolved.

@ojeda ojeda force-pushed the indirect-branch-cs-prefix branch from 879a3bc to 331c2b6 Compare June 15, 2025 12:47
@rustbot rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jun 15, 2025
@ojeda ojeda marked this pull request as ready for review June 16, 2025 04:39
@rustbot
Copy link
Collaborator

rustbot commented Jun 16, 2025

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@ojeda ojeda changed the title -Zindirect-branch-cs-prefix on top of -Zretpoline* Add -Zindirect-branch-cs-prefix Jun 16, 2025
@Darksonn
Copy link
Contributor

Darksonn commented Jul 2, 2025

Assigning same reviewer as #135927.

r? @davidtwco

@rustbot rustbot assigned davidtwco and unassigned compiler-errors Jul 2, 2025
@davidtwco
Copy link
Member

In the last RfL meeting we discussed this flag and clarified that this isn't useful w/out retpoline but you also might not always want it with retpoline, and with that context, it was left as a t-compiler decision whether or not to keep it a separate flag - for consistency with other language toolchains - or add it as a modifier to the retpoline flag - which is more consistent with our other flags. Given that, maybe it's best we don't re-use the MCP for retpoline and open a new one to put that question to the team. I think I lean towards a separate flag for something like this that's quite niche.

Copy link
Member

@davidtwco davidtwco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation otherwise looks good to me

//@ only-x86_64
// FIXME: Are these required?
//@ ignore-apple Symbol is called `___x86_indirect_thunk` (Darwin's extra underscore)
//@ ignore-sgx Tests incompatible with LVI mitigations
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surprised that these would be required w/ only-x86_64

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember I needed those in the past for similar tests, but we can give it a try without them -- let me remove them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we still try to match the __x86_indirect_thunk without the extra underscore, if an extra underscore is also added in Darwin for that case like it is for __x86_return_thunk, then I suspect we may still need at least that one, but we will see.

(I guess we could modify the match expression below, but if so we should probably do it in all of them)

@ojeda
Copy link
Contributor Author

ojeda commented Jul 9, 2025

In the last RfL meeting we discussed this flag and clarified that this isn't useful w/out retpoline but you also might not always want it with retpoline, and with that context, it was left as a t-compiler decision whether or not to keep it a separate flag - for consistency with other language toolchains - or add it as a modifier to the retpoline flag - which is more consistent with our other flags. Given that, maybe it's best we don't re-use the MCP for retpoline and open a new one to put that question to the team. I think I lean towards a separate flag for something like this that's quite niche.

Sounds good, I will send it.

This is intended to be used for Linux kernel RETPOLINE builds.

Signed-off-by: Miguel Ojeda <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-rust-for-linux Relevant for the Rust-for-Linux project A-rustdoc-json Area: Rustdoc JSON backend F-target_modifiers `#![feature(target_modifiers)]` S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants