s390x: replace -Ctarget-feature=+backchain with -Cforce-frame-pointers

[fneddy]

Summary

On s390x, the backchain LLVM function attribute saves the "unwind" (backchain) pointer (r15) into the caller's parameter area, enabling external stack unwinders (e.g. Linux perf) to walk the call chain. Previously this was enabled via -Ctarget-feature=+backchain, which piggy-backed on the target-feature machinery even though backchain is not a CPU or ISA feature.

This commit introduces a cleaner mechanism:

• -Cforce-frame-pointers now enables the "backchain" LLVM function attribute on s390x, rather than the generic "frame-pointer" attribute used on other architectures.
• -Ctarget-feature=+backchain emits a error pointing to the new mechanism.
• Other reasons to set frame pointers (e.g. -Zinstrument-mcount) are unaffected and still emit "frame-pointer".
• All s390x-specific frame-pointer/backchain/packed-stack logic is consolidated in s390x_fn_attrs() in attributes.rs.

This implements the proposed solution discussed in here on Zulip.

Background

Frame pointers on s390x

Setting -Cforce-frame-pointers=yes on s390x forces the "frame-pointer" LLVM attribute, but this does not form a traversable linked list. As [@uweigand] explained ([#150766 comment]):

Even if we force frame pointer registers to be used, those are not stored on the stack in a way that forms a linked list that can be followed. The -mbackchain option simply generates prolog code that manages an equivalent linked list of stack frames at runtime.

Therefore -Cforce-frame-pointers on s390x provides no stack-walking benefit.

Backchain

The s390x ELF ABI reserves backchain slot - a pointer back to the caller's frame. This can be used to walk the entire call chain without DWARF CFI. LLVM exposes this as the "backchain" function attribute, equivalent to GCC's -mbackchain.

Backchain is not a CPU capability. It is a whole-binary code-generation convention, similar in nature to -fno-omit-frame-pointer on x86. This is reflected in LLVM modelling it as a function attribute, not a target feature [#150766 comment 2].

Enabling backchain does not break ABI compatibility: backchain-enabled and -disabled functions can freely call each other.

The one notable exception is packed-stack: combining -Zpacked-stack with backchain on a non-softfloat target is rejected at compile time([#152432]).

rustc arg discussion

Initially backchain was introduced as an unstable target-feature mimicing the gcc and clang behavior. Within the grater effort of stabilizing arguments that are needed for Linux Kernel development, attempts where made to stabilize the target-feature=+backchain. This lead to discussions and the overall consent is that:

1. on s390x, enabling normal frame-poitners will never be done by the user.
2. if a user wants frome-pointers the user actually wants: stack-unwinding on x86 via frame-pointers but on s390x via backchain
3. -Cforce-frame-pointers=yes should on s390x enable backchain and NOT the frame-pointer attribute
4. the old -Ctarget-feature=+backchain pattern should emit a nice error and point to -Cforce-frame-pointers=yes
5. the kernel folks are ok with an instant change of behaviour without a deprecation period

References

• rustc_target: add known safe s390x target features #127506
• s390x-unknown-linux-gnu: cfg!(target_feature = "backchain") is always true #129927
• s390x: Fix a regression related to backchain feature #129940
• When should cfg(target_feature = "backchain") (s390x target feature) be enabled? #142412
• Tracking Issue for s390x_target_feature #150259
• added support for s390x target features soft-float and packed-stack #150766 (comment)
• added support for s390x target features soft-float and packed-stack #150766 (comment)
• Add s390x-unknown-none-softfloat with RustcAbi::Softfloat #151154
• add rustc option -Zpacked-stack #152432
• Tracking Issue for -Ctarget-feature=+backchain #158014
• stabilize s390x specific target-feature backchain #158612
• s390x: replace -Ctarget-feature=+backchain with -Cforce-frame-pointers #163315

[rustbot]

r? @chenyukang

rustbot has assigned @chenyukang.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 77 candidates
• Random selection from 22 candidates

[chenyukang]

@rustbot reroll

[fneddy]

Ok. the problem is now: the ci runs the tests with --pass=check which will NOT run the codegen pass. Therefore obsolete warning is not emitted.

Either I add manual checking into an earlier stage.
Or I add a new target_feature pub enum Stability flag for deprecated/obsolete features.

Or I just move the warning to creation time of the codegen_llvm unit :)

[beetrees]

Per #t-compiler/major changes > Introduce new -C flag for cross-target c… compiler-team#1027 @ 💬 I think this needs an MCP, r? @davidtwco

[fneddy]

my understanding is that we need the MCP as soon as the -Zunstable-options requirement is dropped. If we need it now for this I will take some days and update all mid next week.

[beetrees]

My impression from the Zulip thread and the MCP RFC is that an MCP is generally for when the (unstable) flag is being added, with a rfcbot FCP required for stabilisation.

[dev-japo]

Thanks for looking into this. From my perspective, a hard switch would be perfectly fine. The grace period actually caused some confusion on my side, and I don't think there's much value in carrying both variants for a transition period.

While enabling Rust support for s390 in the Linux kernel, I ended up using this argument as well, and I'd be happy to adapt to the new form directly. Redirecting the argument from one version to the next sounds like a good solution to me.

[Darksonn]

I think it'd be very confusing for -Cforce-frame-pointers + -Zunstable-options to have different behavior from -Cforce-frame-pointers.

[rustbot]

Target features are being changed; ensure all ABI effects are being accounted for

cc @RalfJung

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.