stabilize s390x specific target-feature backchain

[fneddy]

View all comments

Stabilization report: s390x backchain target feature

Summary

This stabilizes the s390x (SystemZ) target feature backchain.

When backchain is enabled, the function prologue stores the caller's stack
pointer into the first slot (the backchain slot) of the function's stack
frame. This links all stack frames into a chain that can be walked without
DWARF/CFI unwind information, which is how the Linux kernel unwinds the stack
on s390x. The primary motivation for stabilization is Rust-for-Linux: the s390x
kernel is compiled with backchain enabled (-mbackchain in GCC/Clang), and
Rust kernel code must match.

backchain is not a hardware (ISA) capability — it is a pure codegen option,
available on every s390x CPU. The feature name matches LLVM's SystemZ feature
backchain; GCC and Clang expose the same functionality as -mbackchain.

Tracking:

• Tracking Issue for -Ctarget-feature=+backchain #158014
• Tracking Issue for s390x_target_feature #150259

Reference PRs:

• S390X stabilize backchain reference#2317

What is stabilized

On s390x targets, backchain becomes a stable target feature, i.e. all of the
following are accepted on stable without warnings:

// per function
#[target_feature(enable = "backchain")]
pub fn in_kernel_context() { ... }

// detection of a compiler-enabled backchain
#[cfg(target_feature = "backchain")]
fn walk_backchain() { ... }

and on the command line:

rustc -Ctarget-feature=+backchain ...

What isn't stabilized

• All other s390x target features (vector-* extensions were stabilized
  separately in 1.93 via s390x_target_feature_vector; the remaining ISA
  features stay gated behind s390x_target_feature).
• -Zpacked-stack (the GCC -mpacked-stack equivalent) remains unstable; only
  its interaction with backchain is relevant here (see below).
• soft-float remains unstable.

Design

Reference

The Reference documents stable target features per architecture in
attributes/codegen.md. A PR adding backchain to the s390x table accompanies
this stabilization: rust-lang/reference#2317

RFC history

None. Target features are added and stabilized through the tracking-issue /
stabilization-report process rather than the RFC process.

Answers to unresolved questions

The tracking issue (#150259) listed one unresolved question about
the packed-stack interaction (#152432). It has no impact on
backchain itself, which stays a regular target feature matching how LLVM
models it; the packed-stack combination is handled as described in Key points.
No unresolved questions remain.

Post-RFC changes

None (no RFC; see above).

Key points

The only design decision of note is how to handle the interaction with the
(unstable) -Zpacked-stack option. A packed stack frame has no backchain
slot unless soft-float is also enabled, so the packed-stack + backchain +
hard-float combination cannot be lowered and makes LLVM ICE. rustc rejects
it up front with a dedicated hard error (#152432). backchain on
its own is uncontentious: it is a pure, additive codegen option available on
every s390x CPU.

Nightly extensions

The remaining s390x ISA target features stay gated behind
s390x_target_feature, and -Zpacked-stack and soft-float remain unstable.
Stabilizing backchain commits us to nothing about those: it is a single,
self-contained codegen flag whose only cross-feature interaction
(packed-stack) is guarded by a hard error (see Key points).

Doors closed

None. backchain maps directly onto the LLVM backchain feature and the
established -mbackchain semantics shared with GCC/Clang, so stabilizing it
does not constrain future language or target-feature work.

Feedback

Call for testing

No formal "call for testing" was issued. The feature has been exercised on
nightly by the Rust-for-Linux s390x work (see Nightly use).

Nightly use

The known nightly consumer is Rust-for-Linux: the s390x kernel is built with
-mbackchain, so Rust kernel code targeting s390x must enable backchain to
match. This is the motivation for stabilization.

Implementation

Major parts

• rustc_target: add known safe s390x target features #127506
• s390x: Fix a regression related to backchain feature #129940
• Extract some shared code from codegen backend target feature handling #140920
• add rustc option -Zpacked-stack #152432
• remove redundant backchain attribute in codegen #152486
• Add s390x-unknown-none-softfloat with RustcAbi::Softfloat #151154

Coverage

• tests/codegen-llvm/backchain.rs — -Ctarget-feature=+backchain results in
  the +backchain LLVM function attribute.
• tests/assembly-llvm/s390x-backchain-toggle.rs — the prologue actually
  stores the backchain when enabled (+backchain), and does not when disabled
  (-backchain) or by default.
• tests/ui/target-feature/packedstack-combinations.rs — the
  packed-stack/backchain interaction: rejected on hard-float targets
  whether backchain comes from #[target_feature] or -Ctarget-feature,
  accepted on s390x-unknown-none-softfloat.
• tests/codegen-llvm/packedstack.rs — packed-stack attribute emission on
  the soft-float target.
• tests/ui/check-cfg/target_feature.rs — backchain is a known value for
  cfg(target_feature).

There are no known or intentional gaps in coverage.

Outstanding bugs

None. The former blocker #142412 is fixed.

Outstanding FIXMEs

None.

Tool changes

None required — target features need no support from these tools beyond what
exists generically.

• rustfmt
  • Not applicable.
• rust-analyzer
  • Not applicable.
• rustdoc (both JSON and HTML)
  • Not applicable.
• cargo
  • Not applicable.
• clippy
  • Not applicable.
• rustup
  • Not applicable.
• docs.rs
  • Not applicable.

Breaking changes

None. This stabilization only makes an already-existing nightly target feature
available on stable; it does not change the meaning of any existing code, so no
crater run is applicable.

Crater report:

• Not applicable.

Crater analysis:

• Not applicable.

PRs to affected crates:

• Not applicable.

Type system, opsem

Compile-time checks

The only compile-time check is the rejection of the invalid packed-stack +
backchain + hard-float combination, which LLVM cannot lower and would ICE
on. rustc emits a dedicated hard error up front (#152432); see
Coverage for the test.

Type system rules

No new type system rules. backchain is governed by the existing
target_feature 1.1 rules for enabling and detecting target features; it adds
no feature-specific typing rules.

Sound by default?

Yes. It does not change the calling convention or any type's ABI: the
backchain slot is part of the standard s390x ELF ABI stack frame layout, and
the feature only controls whether the prologue stores into it. Since it is not
a hardware
capability (see Summary), the #[target_feature] caller obligation is trivially
satisfied on every s390x CPU, so no unsafe opt-in is needed.

Breaks the AM?

No. It cannot introduce undefined behavior or expose the underlying
assembly-level implementation. The one invalid combination is rejected at
compile time (see Compile-time checks).

Common interactions

Temporaries

Not applicable. The feature introduces no new expressions and therefore no new
temporaries.

Drop order

Not applicable. The feature does not affect the order in which values are
dropped.

Pre-expansion / post-expansion

Not applicable. backchain raises no new pre- vs. post-expansion questions; it
is handled like any other target feature in #[target_feature] and
cfg(target_feature).

Edition hygiene

Not applicable. The feature is not gated on an edition.

SemVer implications

No new hazards beyond those that already apply to #[target_feature]
generally. As with any target feature, adding or removing
#[target_feature(enable = "backchain")] on a public function can affect
whether it can be used as a plain function pointer, so it follows the existing
target_feature conventions; backchain introduces nothing beyond that.

Exposing other features

None. Its only interaction with an unstable feature is the guarded
-Zpacked-stack combination (see Key points); no packed-stack behavior leaks
onto stable.

History

See Major parts for the annotated implementation PRs. Additional context not
listed there:

• When should cfg(target_feature = "backchain") (s390x target feature) be enabled? #142412
• Tracking Issue for s390x_target_feature #150259
• Tracking Issue for -Ctarget-feature=+backchain #158014

Acknowledgments

• @liushuyu — initial implementation of the backchain target feature
• @RalfJung — target-feature unification, cfg-detection fix, ABI review
• @uweigand — s390x maintainer, architecture expert
• @fneddy — packed-stack support, soft-float target, this stabilization

No one who worked on this has objected to stabilizing it now.

Open items

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
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 73 candidates
• Random selection from 17 candidates

[ehuss]

As this is an architecture specific option I did NOT update the the docs and
did NOT write a stabilization report

Target features always need to be documented (example from a past s390x stabilization).

Also, since these always need a lang FCP, they generally need a written proposal as to what is being stabilized in order for them to make a decision.

[RalfJung]

According to target expert @uweigand, there are no ABI concerns with this feature (having some parts of the code compiled with and some without can lead to poor backtraces but doesn't break anything worse than that). So 👍 from the ABI side.

[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.

[fneddy]

ok, I think for backchain stabilization this should be it.

[RalfJung]

So you mean this?
@rustbot ready
Please always run these commands, it's easy for PRs to get lost otherwise.

[traviscross]

Thanks @fneddy.

@rfcbot fcp merge lang

[rust-rfcbot]

@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• not-target-feature (stabilize s390x specific target-feature backchain #158612 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[Darksonn]

I don't really think that -Cbetter-stack-traces is the way we want to go here. For one, people are talking about having it imply "force frame pointers" on some targets, and while frame pointers does let you do stack walking for stack traces, it walks the actual stack frames, which means that inlined functions are lost. I would expect the "better" stack traces option to be the one that also tells me about inlined functions via DWARF debugging information or whatever, because the one that doesn't seems like the cheap version of stack traces. The same applies to backchain.

And if we think that all these weird target options that aren't target features shouldn't be a bunch of top-level compiler flags, then okay we could group them under some sort of new category like -Ctarget-option=backchain or whatever, but let's not block -Zbackchain on it. It's just the <big number>th example of the same pattern we've repeated many times with -Zfixed-x18, -Zbranch-protection, -Zharden-sls and many others.

[uweigand]

-Cbetter-stack-traces=yes should then enable the mechanism that the Linux Kernel ORC "unwinder" uses?

ORC is something else again (which isn't even supported on s390x at the moment).

[RalfJung]

The point of those flags is that they heuristically give you better stack traces. Not perfect, but better. It trades off some other qualities to achieve that. The rest is an implementation detail. No reason to make the perfect (dwarf-based) the enemy of the better. I wouldn't even know to look for "frame pointers" to achieve that. The current flag is putting obscure low-level jargon first rather than the actual intent users typically have. It's also kind of silly that I have to know to use various different flags to portably achieve the same effect.

[hanna-kruppe]

My two cents on the intent/naming of the frame pointers flag: on architectures I’m familiar with (not s390x), enabling universal frame pointers is not about better (higher quality) stack traces, but about being able to capture a stack with a very simple and fast implementation, not needing the complexity of unwind tables. This matters when you capture a lot of stack traces and can symbolicate them separately.

If you don’t care about implementation complexity or speed of capturing stack traces (and unwinding is a thing on your platform), you can use instead use -Cforce-unwind-tables to get the same quality of stack traces and probably get slightly smaller and/or faster executable code. (Though the binary on disk may be larger if you wouldn’t otherwise need unwind tables.)

[uweigand]

My two cents on the intent/naming of the frame pointers flag: on architectures I’m familiar with (not s390x), enabling universal frame pointers is not about better (higher quality) stack traces, but about being able to capture a stack with a very simple and fast implementation, not needing the complexity of unwind tables. This matters when you capture a lot of stack traces and can symbolicate them separately.

Yes, exactly - it's the same on s390x. With the main exception that on s390x (and some a few platforms), forcing frame pointers on universally does not actually allow this simple and fast stack walk either! Instead, to achieve this same purpose, you need to use a different mechanism (which is enabled via -mbackchain in other s390x compilers). That's why we're having the naming discussion - should the name of the flag reflect the particular mechanism (which may differ between platforms), or the intended purpose (which is the same).

If you don’t care about implementation complexity or speed of capturing stack traces (and unwinding is a thing on your platform), you can use instead use -Cforce-unwind-tables to get the same quality of stack traces and probably get slightly smaller and/or faster executable code. (Though the binary on disk may be larger if you wouldn’t otherwise need unwind tables.)

We can do this on s390x as well, but only in user space (where it's actually the default). This whole discussion is about the Linux kernel, where unwind tables cannot be used as the kernel does not support DWARF CFI parsing (due to implementation complexity concerns).

[RalfJung]

My two cents on the intent/naming of the frame pointers flag: on architectures I’m familiar with (not s390x), enabling universal frame pointers is not about better (higher quality) stack traces, but about being able to capture a stack with a very simple and fast implementation, not needing the complexity of unwind tables. This matters when you capture a lot of stack traces and can symbolicate them separately.

Sure, my -C name was just a first sketch since I don't know the details that well.
-Cfast-stack-traces or so?

[fneddy]

I have some remarks, concerns and questions on this. I hope to not overwhelm everybody, but nevertheless wanted to address all of it here at least once:

My understanding:

• -Ctarget-feature=.. does things hat are target specific and may have effects on the ABI
• -Z/-C options are arguments and options that will change the behavior of how rustc will emit code
• backchain is not ABI breaking by itself
• why backchain is (currently) a target feature:
  • because its a target feature in clang/gcc
  • because it has side-effects with packed-stack what result in a dependency to soft-float and that is ABI breaking.
• -Cfast-stack-traces would be a thing you would not want to enable by default(!?)

Remarks:

• We planed to also make packed-stack a target-feature so:
  • it matches clang/gcc
  • its clear it may have side-effects on the ABI
• I think the ONLY situations when you want to enable backchain on s390x are:
  • compiling kernel code
  • compiling code for perf profling

Concerns

• -Cfast-stack-traces looks like a thing you might want, as it makes things faster. However it will NEVER make your code run faster.
• the only people who currently want backchain are kernel developers. They know exactly what they want and why.
• this developers who actually need this will look for options with the names they are used to from clang/gcc.
• IMHO hiding a platform specific option behind a generic name (-Cfast-stack-traces) will result in confusion:
  • it does different things on different platforms
  • you may come to a situation where it enables TargetA:FeatureX, TargetB:FeatureY, TargetC:FeatureZ but the developer does not want Option2 and has to build complicated target specific logic around -Cfast-stack-traces

Questions

• Is it ok that -Cfast-stack-traces would have side-effects with other arguments that may break ABI (Yes we catch this and error out) ?
• Is it ok to have a different UI as clang/gcc for the same codegen option?
• Is it ok that inexperienced users will enable -Cfast-stack-traces as its name implys something good and desirable, however it has no use to them?
• How should -Cfast-stack-traces handle a mix of stable/unstable features? e.g. It might happen that this option is stable on some targets and unstable on others. I can even imagine a situation where one wants add an option or feature on a specific target and thus -Cfast-stack-traces moves from stable to unstable.

[RalfJung]

-Ctarget-feature=.. does things hat are target specific and may have effects on the ABI

Most target features don't affect the ABI. It was a bit of a shock for us when we learned that some do, and that caused a series of soundness issues and a bunch of new code to deal with this.

because its a target feature in clang/gcc

They don't really have that notion, do they? Or do you mean "it's a -m flag rather than a -f flag"?

-Cfast-stack-traces looks like a thing you might want, as it makes things faster. However it will NEVER make your code run faster.

I'm open to other names. :)

-Cmake-simple-stack-tracing-possible. 🤷

this developers who actually need this will look for options with the names they are used to from clang/gcc.

Just because GCC/clang picked a bad UI that leaks implementation details, does not mean we have to copy their mistakes.

Is it ok that -Cfast-stack-traces would have side-effects with other arguments that may break ABI (Yes we catch this and error out) ?

It's just a particular flag configuration being unsupported, I don't think this is the only such case.

How should -Cfast-stack-traces handle a mix of stable/unstable features? e.g. It might happen that this option is stable on some targets and unstable on others. I can even imagine a situation where one wants add an option or feature on a specific target and thus -Cfast-stack-traces moves from stable to unstable.

The idea for this flag would be that we don't make hard guarantees for what it does, we just say "currently, it does the following on these targets: [...]". So we can change what it does without that having to go through the unstable feature process.

If that sounds like a bad idea then we probably shouldn't do it.

[Darksonn]

The idea for this flag would be that we don't make hard guarantees for what it does, we just say "currently, it does the following on these targets: [...]". So we can change what it does without that having to go through the unstable feature process.

I definitely do not want a single flag that provides different backtrace mechanisms on different versions of rustc. In Linux, we'll need to make sure that Rust and C use the same mechanism, and this would make that a lot harder. We would have to start hard-coding the version numbers at which rustc switches from one mechanism to another in our makefiles.

[Mark-Simulacrum]

One is users of tooling like Linux's perf, backtrace, and similar tooling that should make use of what it can find in the binary to figure out what the stack is at any given point in time. For the most part users of this tooling don't care how that goal is actually accomplished (I think), they just want it to work. For that usecase, it seems like -Cstack-trace is a pretty nice option - it means as a user I can mostly just expect things to work. For e.g. the Cargo profile interface, it seems like that is probably what we'd want semantically, rather than having both frame pointers and backchains and SFrames and whatever other option comes along exposed.

I think there is a legitimate need for requesting a particular implementation of the "fast stack trace" or whatever we call it that you're calling out -- cross-compiler interop. I could see that being an optional parameter, e.g., -Cstack-trace={default,backchain,frame-pointer,sframe}.

We could also add this to -Cdebuginfo as backchain, e.g., you could write:

-Cdebuginfo=backchain
-Cdebuginfo=+frame-pointers,line-tables-only # both DWARF and frame pointers
-Cdebuginfo=fast-stack # or some other name indicating either frame pointers or
                       # backchain or whatever the compiler prefers as the "fast unwind" implementation.

Ultimately if the only targets that don't use frame pointers are less frequently used ones (e.g., s390x), maybe the cost of designing a nice option for this isn't worth it and we could stabilize it under -Ctarget-feature or -Cbackchain. It does seem like there's opportunity to provide a better cross-target experience here.

[hanna-kruppe]

First, I agree that rustc definitely needs to expose the same control over low-level platform-specific details what code and metadata gets emitted as other toolchains. I think it's also really important to expose them under recognizably similar names. Not only for specific interop needs, but also because there is a lot of existing material and knowledge out there and in people's heads that speaks about frame pointers even though it's technically incorrect and not completely portable. I don't think rustc flag names are a good place to get pedantically pedagogic about this. So as long as there's nothing really broken about -mbackchain (e.g., ABI issues), I think we should have an option that's obviously the direct equivalent of -mbackchain and nothing more, and leave -Cforce-frame-pointers as closest equivalent of -f[no-]omit-frame-pointer (details differ but it’s clearly the same concept, including being of dubious value on s390x).

Given that such a low level knobs need to exit, I'm skeptical about doing a larger redesign of rustc flags at the same time to also address portability, unify, simplify, or address user intent more directly. I understand the urge to do so, but even ignoring the "is it worth the effort for relatively niche targets" aspect, it seems hard to do well. Just a couple points:

• There are multiple distinct reasons why one might want to control the underlying mechanisms here. @Mark-Simulacrum already illustrated this by mentioning both -Cstack-trace and extending -Cdebuginfo as options.
• At the same time, not all of the possible values fit equally well everywhere. For example, -Cdebuginfo=backchain looks weird to me (it's not what I'd consider debug info).
• The "frame pointers" option alone is more complex than a yes/no (e.g., does it apply to all functions or can leaf functions skip it?), although this is not currently exposed by -Cforce-frame-pointers (only in target specs). Collapsing this and other options into one bigger option with more values makes it harder to deal with such nuances.
• Addressing a very specific use case such as "I want meaningful perf output" may allow taking care of setting various flags to what rustc considers the best way to achieve that goal, but I think there's way too many potential use cases to bake this into rustc.
• If you instead go with more vague "I want fast stack traces" then whatever you do will be wrong for some (or many) contexts where the flag sounds appropriate but whatever assumptions rustc makes are wrong. For example, frame pointers / backchain is great for perf, while samply is much better at CFI-based unwinding, so when I use the latter -Cforce-unwind-tables=on -Cdebuginfo=line-tables-only is a better choice in my experience.

In addition, it's not obvious to me that rustc flags are the best place to achieve these goals. Cargo profile settings (if any) have much more direct impact on most users, and Cargo profile settings don't necessarily have to map 1:1 to rustc flags. There's also tools like cargo-wizard for translating user intent into appropriate Cargo configuration.

So I don't think this PR / stabilization is a good place to try and tackle this much larger problem. Let's spin that off into a separate thread and not block the s390x-specific low-level compiler knob on it.

[RalfJung]

One of the big value-adds of Rust is that we are not just repeating the mistakes of C and C++, so "we should use their names even if we all agree they are terrible" is IMO not a good argument. rustc flag names are as good a place to get pedagogic about this as the Rust standard library and the language itself, and there we deliberately make our own choices all the time, often with great success.

So I don't think this PR / stabilization is a good place to try and tackle this much larger problem. Let's spin that off into a separate thread and not block the s390x-specific low-level compiler knob on it.

So are you saying we should add -Cbackchain or are you saying we should make it a target feature even though it's not really reflecting some CPU capability (which is what we usually use target features for)?

[hanna-kruppe]

I don't (yet?) have a strong opinion on how to spell the target-specific flag for controlling this aspect of codegen. It could be a target feature, or a new top level flag -C bikeshed-backchain=[on|off], or maybe we want to group this with some other flags under a new -C bikeshed=+backchain,-frobnication,... flag. This does seem more similar to flags like -Cno-redzone, -Zfixed-x18 than to target features, but as I said, I don't have strong opinions.

What I am saying is that we should have that low-level, target-specific flag in some form. I don't see a good way to not have that flag. Maybe if another target (PPC?) has basically the same mechanism, we can have a common flag for that, similar to e.g. -Cno-redzone means different implementations of the same concept depending on the target. But I don't think it should be lumped together with -Cforce-frame-pointers (more on this below) and I don't think we can avoid exposing the low-level mechanism in rustc's CLI interface.

Centering user stories like "profiling" or "better backtrace on panic" means not guaranteeing what concrete mechanism it maps to. As discussed above, that's insufficient because sometimes the user's intent is to pick the mechanism. We may still want to have flags aimed at those use cases, but as they touch many areas that are currently separate stable flags, it seems like a different feature that should be designed separately.

If we center the low-level mechanisms of stack-walking, then the available options, what they mean, and their trade-offs are necessarily platform-specific to some extent. There is some commonality between "things that let you walk the stack but not actually unwind it" (frame pointers, backchain, SFrame, ORC), which may suggest a new -C flag to group these options. But there are too many context-dependent trade-offs to boil it down to a single target-dependent on/off switch, so the individual mechanisms must still be listed and named somehow.

And if you expose the individual platform specific mechanisms, you have to name them. In that context I don't think there's anything really wrong with backchain being distinct from frame-pointers:

• Calling the mechanism that this PR is about "frame pointers" is confusing and wrong, because (as others explained above) frame pointers also exist on the relevant target and is distinct from the backchain convention. This is not about matching an arbitrary name or taxonomy made up by C compilers, frame pointers are a well-established and mostly target-independent concept in ABIs. The usefulness of that pointer for stack walking is target-dependent, but that goes back to user stories rather than mechanisms.
• We could invent a new name for "frame pointers or backchain" based on their commonality and frame pointers being mostly pointless on targets where the distinction exists. But migrating away from the well-established "frame pointer" terminology (incl. -Cforce-frame-pointers) on the many targets where it's exactly what you want seems like unnecessary churn to me. We'd also have to be very confident that there will never a reason to e.g. enable frame pointers on a target that has another similar mechanism, otherwise we're back to needing names for both mechanisms.

[RalfJung]

Centering user stories like "profiling" or "better backtrace on panic" means not guaranteeing what concrete mechanism it maps to. As discussed above, that's insufficient because sometimes the user's intent is to pick the mechanism.

Alice also said that above. This is a fair point, I agree we need to maintain a way to control the mechanism.

This could be achieved by having specific values for such a -C flags, like -Cstack-walking-support=frame-pointers vs -Cstack-walking-support=backchain. Unspecific values such as -Cstack-walking-support=yes could then mean "just do whatever is best for the current target, if possible".

(Note that I don't have made up my mind about this yet, I am just throwing ideas into the room.)

[RalfJung]

It is worth mentioning that we already have at least one target feature that's arguably not a target feature: -Ctarget-feature=+crt-static. It seems we are viewing that as a mistake now? I would say -Ctarget-feature=+backchain is no more weird than +crt-static.

[RalfJung]

I filed an MCP for the compiler team to discuss what the codegen option should look like: rust-lang/compiler-team#1027.

[rust-bors]

☔ The latest upstream changes (presumably #160725) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[traviscross]

Let's cancel that FCP...

@rfcbot fcp cancel

Please renominate if, after discussion, there are further questions for lang.

[rust-rfcbot]

@traviscross proposal cancelled.