tests: Test pac-ret flag merging on clang with LTO #133045
Conversation
rustbot
added
A-run-make
|
This PR modifies cc @jieyouxu |
|
@bors try |
| @@ -32,5 +35,15 @@ fn main() { | |||
| .input("test.rs") | |||
| .output("test.bin") | |||
| .run(); | |||
|
|
|||
| // Check that both a-key and b-key pac-ret survived LTO | |||
There was a problem hiding this comment.
Question: is there any background / links for this? I'm fine with the change, but it's even better if there's any kind of context to read.
There was a problem hiding this comment.
For sure, this is the context:
llvm/llvm-project@1782810
TLDR: there was a bug in LLVM where during the LTO step instructions like "pacibsp" would get replaced with "paciasp" due to LLVM module flag merging behaviour. As currently written the assembly output should have no PAuth on library functions, paciasp at the start of main and pacibsp at the start of foo.
It is worrying that the test is failing, I'll try to reproduce it locally.
There was a problem hiding this comment.
Thanks for the context. And I agree, the test failing is... suspicious lol. Can you please include your reply as a test comment to help a $FUTURE_READER not have to find this PR to understand the context?
There was a problem hiding this comment.
Also it might help if you do something like let clang_version = clang().arg("-v").run(); and then print that to double-check what clang version CI has.
There was a problem hiding this comment.
Okay this is very funny
00000000000677a4 <test::main>:
677a4: d503233f paciasp
677a8: d50323bf autiasp
677ac: d65f03c0 ret
The test fails because the compiler optimises away the entire call to foo and its pac instructions along with it. I'll fix it..
There was a problem hiding this comment.
Right... That can explain it lol. black_box to the rescue.
…-merge, r=<try> tests: Test pac-ret flag merging on clang with LTO Extend the test for pac-ret with clang and LTO by checking that different branch protection flags are preserved after the LTO step. There was an issue in older LLVM versions that was causing this to behave incorrectly. try-job: aarch64-gnu-debug
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-author
Extend the test for pac-ret with clang and LTO by checking that different branch protection flags are preserved after the LTO step. There was an issue in older LLVM versions that was causing this to behave incorrectly. Tests the LLVM behaviour added in: llvm/llvm-project@1782810
mrkajetanp
force-pushed
the
pauth-test-clang-lto-flag-merge
branch
from
ab13be7
to
194471c
Compare
|
Dropping that opt flag makes it work for me, could you have bors try it again? |
|
Sure. @bors try |
…-merge, r=<try> tests: Test pac-ret flag merging on clang with LTO Extend the test for pac-ret with clang and LTO by checking that different branch protection flags are preserved after the LTO step. There was an issue in older LLVM versions that was causing this to behave incorrectly. try-job: aarch64-gnu-debug
|
☀️ Try build successful - checks-actions |
|
@bors r+ rollup (only runs in one CI job that was tested here). |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#132817 (Recurse into APITs in `impl_trait_overcaptures`) - rust-lang#133021 (Refactor `configure_annotatable`) - rust-lang#133045 (tests: Test pac-ret flag merging on clang with LTO) - rust-lang#133049 (Change Visitor::visit_precise_capturing_arg so it returns a Visitor::Result) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#133045 - mrkajetanp:pauth-test-clang-lto-flag-merge, r=jieyouxu tests: Test pac-ret flag merging on clang with LTO Extend the test for pac-ret with clang and LTO by checking that different branch protection flags are preserved after the LTO step. There was an issue in older LLVM versions that was causing this to behave incorrectly. try-job: aarch64-gnu-debug
Extend the test for pac-ret with clang and LTO by checking that different branch protection flags are preserved after the LTO step. There was an issue in older LLVM versions that was causing this to behave incorrectly.
try-job: aarch64-gnu-debug