Introduce new -C flag for cross-target control of stack walking features

Proposal

"backchain" is an LLVM target feature for s390x that adjust codegen in a way that stack walking (for the purpose of printing a backtrace) becomes easier or even possible. In that sense it is similar to frame pointers on other targets, though the implementation is different. See https://github.com/rust-lang/rust/issues/158014 for more context.

In https://github.com/rust-lang/rust/pull/158612, the lang team objected to exposing the "backchain" LLVM target feature as a Rust target feature, since "It specifically isn't a target feature; it's just a codegen option, like enabling frame pointers". And indeed this does not reflect a target CPU capability, making it unlike most of our target features. (But it is worth mentioning that we have -Ctarget-feature=+crt-static, which is not even a codegen option, it's more of a linker option. So if we are serious about target features being used only for CPU capabilities, we should consider deprecating -Ctarget-feature=+crt-static in the long term. This MCP does not propose anything like that, I just mentioned it for context.)

So, this is the proposal to add such a codegen option. In https://github.com/rust-lang/rust/pull/158612, two options have been considered to do that:

• add a general -Cstack-walking-support that controls stack walking related options across targets. Values include:
  • yes, meaning "just make stack walking better, if possible, or ignore if that doesn't work"
  • frame-pointers, which is equivalent to -Cforce-frame-pointers=yes. TODO: does it error or is it ignored if frame pointers are not useful for stack walking on the current target?)
  • backchain, which enables the corresponding target feature on s390x. TODO: does it error on other targets?
• add a new -Cbackchain specifically for s390x

I have a mild preference for the former so that's what this MCP proposes.

Mentors or Reviewers

I won't do the implementation but I hope @fneddy can look into that

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Start with this MCP proposal, then read rust-lang/rust issue #158014 and PR #158612 for the stack-walking context and previously discussed options. No implementation files or tests are named; the proposal is complete when the option's design and unresolved behavior across targets are decided through the documented second and Final Comment Period process.