Support stack probing for arm64 (aarch64)

[tmandry]

Background: #43241

This issue is to track implementation of stack probing on arm64. Most of the work necessary is in in LLVM, but this is a convenient place to track progress and final support in the Rust compiler.

Implementation: @cuviper has suggested using LLVM's inline-asm support for stack probing: #43241 (comment). It does not yet support arm64.

External trackers:

• https://linaro.atlassian.net/browse/LLVM-618

[pietroalbini]

@rustbot ping arm

[rustbot]

Hey ARM Group! This bug has been identified as a good "ARM candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @JamieCunliffe @joaopaulocarreiro @raw-bin @Stammark @vigoux

[tmandry]

Hi @raw-bin, what's the status of this? As I recall this work was planned to land as part of LLVM 12, but I haven't seen updates on the Linaro tracker yet.

[raw-bin]

Hi Tyler. I believe there has been progress but let me get the definitive and circle back ASAP. Cheers, Robin

…

On Sat, Feb 13, 2021 at 2:24 AM Tyler Mandry ***@***.***> wrote: Hi @raw-bin <https://github.com/raw-bin>, what's the status of this? As I recall this work was planned to land as part of LLVM 12, but I haven't seen updates on the Linaro tracker yet. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77071 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFMKYURA7T2IXM4NP5ZNGTS6XPEXANCNFSM4RWDXQ2Q> .

[raw-bin]

Hi @tmandry, folks.

Apologies for the delay.

There has been good progress.

Please note the following patches that have been posted by Linaro for review:

https://reviews.llvm.org/D96004
https://reviews.llvm.org/D96005
https://reviews.llvm.org/D96006
https://reviews.llvm.org/D96007

At present Linaro is blocking on review.

If possible, please do chime in.

I will provide further updates as needed.

Cheers

[tmandry]

Great, thanks for the update! Let me ask around to see if I can help get those patches reviewed.

[joshtriplett]

What's the current state of this? What needs to happen to get working stack probes on aarch64?

[pnkfelix]

Visited for T-compiler steering backlog bonanza.

Seems like 3 out of the 4 of the LLVM patches linked above are still undergoing review. So, tagging this as unimplemented. (And also blocked, since its waiting on LLVM review capacity that we really can't do much about ourselves.)

@rustbot label: S-tracking-unimplemented S-blocked

[jacobbramley]

Arm's LLVM team have now picked this up, and have told us that the work should be completed by September at the latest (LLVM 17).

[tstellar]

The deadline to get changes into LLVM17 is the end of July, so September would be too late.

[jacobbramley]

Yes, sorry, I wasn't very clear. They're hoping to get this reviewed and merged in time for the LLVM 17 release branch, which means by the end of July on main. There should therefore be something for us to see and test somewhat earlier than September, but (according to LLVM's release process documentation)17.0.0-final would take at least an additional six weeks, and of course it's possible that issues are found in that testing time.

[jonathanpallant]

Does anyone know if these changes made it in?

[jacobbramley]

They didn't! I'd been tracking it, and all seemed to be going well until recently, so I've been digging a bit to work out what's happened.

It seems that the work was progressing as planned, but hit validation issues, so it missed the LLVM17 code freeze, sadly. It was being tracked in Linaro's LLVM-618, but that doesn't describe the exact problem. I'm still hoping to have it landed on main somewhat before the LLVM18 code freeze, and I've stressed its importance.

I apologise for the further delay!

[jacobbramley]

This is in progress here: llvm/llvm-project#66524 (moved from Phabricator)

[slanterns]

It has been merged. Hopefully we can get it after upgrading to LLVM18.

[cuviper]

Great! If someone wants to try it, you can add stack_probes: StackProbeType::Inline to the options here:

rust/compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_gnu.rs

Line 9 in b10cfcd

options: TargetOptions {

... and build the compiler with your own LLVM 18 / main.

(The inline option should be a no-op on versions where the target didn't support it.)

Then tests/ui/abi/stack-probes.rs can be updated for a functional test, but even just the normal rustc bootstrap process will probably exercise probing enough to see if there are any rough edges.

[cuviper]

I went ahead and tested it myself and found no issues => #118491 flips the switch!

[cuviper]

@erikschul Cross-compilation is a completely different thing -- please open a separate issue.

[adamgemmell]

I've done a top 20k crater run on cuviper's #118491 on an aarch64 machine. I used Rust e51e98d and LLVM c09e6905567a6b546bb2fd9e863511a8fb939b19 and didn't find any non-spurious failures.

[jacobbramley]

Is this issue now complete, or do we need anything else?

[jonathanpallant]

What about the 1 footnote on https://doc.rust-lang.org/nightly/rustc/platform-support.html?

[cuviper]

I think we're done! Aarch64 stack probes are tested in CI (e.g. here and here), and #122094 removed that footnote.

If there are fundamental problems discovered, we can reopen this, otherwise please open new issues for any bugs.