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

[RalfJung]

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 rust-lang/rust#158014 for more context.

In rust-lang/rust#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 rust-lang/rust#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.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler