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
Add -Zfunction-return={keep,thunk-extern}
option
#116892
Conversation
r? @wesleywiser (rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
Note that LLVM ignores the attribute in non-x86, but I have not replicated Clang's check that this only works in x86 for the CLI flag for the moment (should it be part of the target spec?). Also, I linked the feature request issue as the tracking one in the docs -- we can reuse it changing the OP message, I assume, but please let me know if it is best to create a new one. |
8df5004
to
8b6016a
Compare
// FIXME: In principle, the inherited base LLVM target code model could be large, | ||
// but this only checks whether we were passed one explicitly (like Clang does). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is a way to get the effective code model, it would be nice to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe check sess.target.options.code_model
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That covers even less, no? i.e. code_model()
covers codegen and target options.
This comment has been minimized.
This comment has been minimized.
I added a folder but that still counts against the tidy limit in |
One more note: GCC and Clang give an error if one tries to use I did it like this because it seemed simpler (no But perhaps consistency with GCC/Clang is better? |
I moved them inside the other folder, and noticed one in |
The Rust compiler does not support the equivalent of `-mfunction-return=thunk-extern` yet [1]. Thus, currently, `objtool` warns about it, e.g.: samples/rust/rust_print.o: warning: objtool: _R...init+0xa5c: 'naked' return found in RETHUNK build The support in `rustc` for `-Zfunction-return` has been submitted and is being reviewed [2]. It adds the needed LLVM function attributes and, with it, I got a RETHUNK kernel build with Rust enabled that does not print the `objtool` related warnings, boots in QEMU and can load a kernel loadable module. In any case, until proper/complete support is added to `rustc`, make it a hard restriction until the mitigation is in place. This may have an impact for developers that may not need/care about the mitigation in the Rust side (e.g. Ubuntu offers Rust as a "technology preview" [3]), but given we are getting closer to having the first actual in-tree Rust kernel users, it seems like the right time to disallow it. This should also avoid confusion [4]. Link: rust-lang/rust#116853 [1] Link: rust-lang/rust#116892 [2] Link: https://lore.kernel.org/rust-for-linux/ZSQXqX2%2Flhf5ICZP@gpd/ [3] Link: https://lore.kernel.org/rust-for-linux/CANiq72n6DMeXQrgOzS_+3VdgNYAmpcnneAHJnZERUQhMExg+0A@mail.gmail.com/ [4] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
When support for `-Zfunction-return` lands in Rust [1], this patch may be used to enable RETHUNK support on top of the previous patch. Link: rust-lang/rust#116892 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The Rust compiler does not support the equivalent of `-mfunction-return=thunk-extern` yet [1]. Thus, currently, `objtool` warns about it, e.g.: samples/rust/rust_print.o: warning: objtool: _R...init+0xa5c: 'naked' return found in RETHUNK build The support in `rustc` for `-Zfunction-return` has been submitted and is being reviewed [2]. It adds the needed LLVM function attributes and, with it, I got a RETHUNK kernel build with Rust enabled that does not print the `objtool` related warnings, boots in QEMU and can load a kernel loadable module. In any case, until proper/complete support is added to `rustc`, make it a hard restriction until the mitigation is in place. This may have an impact for developers that may not need/care about the mitigation in the Rust side (e.g. Ubuntu offers Rust as a "technology preview" [3]), but given we are getting closer to having the first actual in-tree Rust kernel users, it seems like the right time to disallow it. This should also avoid confusion [4]. Link: rust-lang/rust#116853 [1] Link: rust-lang/rust#116892 [2] Link: https://lore.kernel.org/rust-for-linux/ZSQXqX2%2Flhf5ICZP@gpd/ [3] Link: https://lore.kernel.org/rust-for-linux/CANiq72n6DMeXQrgOzS_+3VdgNYAmpcnneAHJnZERUQhMExg+0A@mail.gmail.com/ [4] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
When support for `-Zfunction-return` lands in Rust [1], this patch may be used to enable RETHUNK support on top of the previous patch. Link: rust-lang/rust#116892 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
☔ The latest upstream changes (presumably #117405) made this pull request unmergeable. Please resolve the merge conflicts. |
Resolved trivial formatting conflict. |
Rebased, added For Darwin, if there is a "standard" way to check for the extra underscore, please let me know (relaxing the regex felt wrong, but perhaps duplicating the cases is OK for this sort of test). Otherwise, LLVM's own test use |
This comment has been minimized.
This comment has been minimized.
Re-blessed tests ( |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This is intended to be used for Linux kernel RETHUNK builds. With this commit (optionally backported to Rust 1.73.0), plus a patched Linux kernel to pass the flag, I get a RETHUNK build with Rust enabled that is `objtool`-warning-free and is able to boot in QEMU and load a sample Rust kernel module. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
A bunch of trivial fixes above. @wesleywiser @Dylan-DPC This is ready again -- let's see if other targets fail in the full CI. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (f45631b): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 674.44s -> 674.191s (-0.04%) |
@wesleywiser Thanks for the very quick review and have a nice holiday (I saw the other PR by chance when looking for this one :) |
Thanks! |
The Rust compiler does not support the equivalent of `-mfunction-return=thunk-extern` yet [1]. Thus, currently, `objtool` warns about it, e.g.: samples/rust/rust_print.o: warning: objtool: _R...init+0xa5c: 'naked' return found in RETHUNK build The support in `rustc` for `-Zfunction-return` has been submitted and is being reviewed [2]. It adds the needed LLVM function attributes and, with it, I got a RETHUNK kernel build with Rust enabled that does not print the `objtool` related warnings, boots in QEMU and can load a kernel loadable module. In any case, until proper/complete support is added to `rustc`, make it a hard restriction until the mitigation is in place. This may have an impact for developers that may not need/care about the mitigation in the Rust side (e.g. Ubuntu offers Rust as a "technology preview" [3]), but given we are getting closer to having the first actual in-tree Rust kernel users, it seems like the right time to disallow it. This should also avoid confusion [4]. Link: rust-lang/rust#116853 [1] Link: rust-lang/rust#116892 [2] Link: https://lore.kernel.org/rust-for-linux/ZSQXqX2%2Flhf5ICZP@gpd/ [3] Link: https://lore.kernel.org/rust-for-linux/CANiq72n6DMeXQrgOzS_+3VdgNYAmpcnneAHJnZERUQhMExg+0A@mail.gmail.com/ [4] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
When support for `-Zfunction-return` lands in Rust [1], this patch may be used to enable RETHUNK support on top of the previous patch. Link: rust-lang/rust#116892 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The Rust compiler does not support the equivalent of `-mfunction-return=thunk-extern` yet [1]. Thus, currently, `objtool` warns about it, e.g.: samples/rust/rust_print.o: warning: objtool: _R...init+0xa5c: 'naked' return found in RETHUNK build The support in `rustc` for `-Zfunction-return` has been submitted and is being reviewed [2]. It adds the needed LLVM function attributes and, with it, I got a RETHUNK kernel build with Rust enabled that does not print the `objtool` related warnings, boots in QEMU and can load a kernel loadable module. In any case, until proper/complete support is added to `rustc`, make it a hard restriction until the mitigation is in place. This may have an impact for developers that may not need/care about the mitigation in the Rust side (e.g. Ubuntu offers Rust as a "technology preview" [3]), but given we are getting closer to having the first actual in-tree Rust kernel users, it seems like the right time to disallow it. This should also avoid confusion [4]. Link: rust-lang/rust#116853 [1] Link: rust-lang/rust#116892 [2] Link: https://lore.kernel.org/rust-for-linux/ZSQXqX2%2Flhf5ICZP@gpd/ [3] Link: https://lore.kernel.org/rust-for-linux/CANiq72n6DMeXQrgOzS_+3VdgNYAmpcnneAHJnZERUQhMExg+0A@mail.gmail.com/ [4] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
When support for `-Zfunction-return` lands in Rust [1], this patch may be used to enable RETHUNK support on top of the previous patch. Link: rust-lang/rust#116892 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is intended to be used for Linux kernel RETHUNK builds.
With this commit (optionally backported to Rust 1.73.0), plus a patched Linux kernel to pass the flag, I get a RETHUNK build with Rust enabled that is
objtool
-warning-free and is able to boot in QEMU and load a sample Rust kernel module.Issue: #116853.