Tracking Issue for `-Ctarget-feature=+backchain`

[fneddy]

This is a tracking issue for the -Ctarget-feature=+backchain feature on s390x.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implement. backchain is already fully implemented. However there is cross influence with other flags and features. (see add rustc option -Zpacked-stack #152432 and Add s390x-unknown-none-softfloat with RustcAbi::Softfloat #151154)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

None

Implementation history

• add rustc option -Zpacked-stack #152432
• Add s390x-unknown-none-softfloat with RustcAbi::Softfloat #151154
• rustc_target: add known safe s390x target features #127506

[ojeda]

@rustbot label +A-rust-for-linux

[ojeda]

Should this use the new -Zllvm-target-feature? (Context, PR) I see backchain in the table of the Rust ones, so perhaps not.

In addition / relatedly, if I understand correctly, the flag can be an ABI concern if mixed with -Zpacked-stack (which the compiler already rejects). Thus, should this be mentioned at #131837?

Finally, there is #150259 -- linking it from here, though I am not sure if it is expected to have individual tracking issues in addition to that one.

Thanks for tracking this!

Cc @RalfJung

[fneddy]

I will check if we can still do the necessary checks with -Zllvm-target-feature.
Currently this checks are not very well tied into one place, but a little scattered. I dislike the current state, maybe I can clean it up a little with this infrastructure.

[RalfJung]

if mixed with -Zpacked-struct (which the compiler already rejects)

Did you mean -Zpacked-stack?

[RalfJung]

Should this use the new -Zllvm-target-feature?

The question is, can one cause ABI trouble by mixing different values for backchain in different compilation units? AFAIK we concluded that no one cannot, but I am not an expert. In particular I wonder what happens if some compilation units use -Ctarget-feature=+backchain, some use -Zpacked-stack, but none of them use both so the check does not get triggered.

Or is -Zpacked-stack a target modifier (i.e. forced to be consistent across the entire crate graph)?

[ojeda]

Did you mean -Zpacked-stack?

Yeah -- fixed there.

[fneddy]

@uweigand had a good write-up about this here¹. In essence: you should NOT combine backchain and packed-stack (unless combined with softfloat for the kernel) in the same compilation unit. We check that in rust² and it also in llvm³. As far as I understand, it its possible to call from backchain to packed-stack and reverse back and forth. I *think* it will break backchain-unwind but call-wise it's all fine.

Footnotes

1. https://github.com/rust-lang/rust/pull/150766#issuecomment-3729074303 ↩

2. https://github.com/rust-lang/rust/blob/main/compiler/rustc_codegen_llvm/src/attributes.rs#L362 ↩

3. https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/SystemZ/SystemZFrameLowering.cpp#L917 ↩

[RalfJung]

you should NOT combine backchain and packed-stack (unless combined with softfloat for the kernel) in the same compilation unit.

(emphasis mine)

As long as that's a per-compilation-unit requirement, not a global one, the current checks should be fine. No reason to use -Zllvm-target-feature.

Though of course if the target maintainers think that backchain should only be changed globally, and it should be impossible to use e.g. a std without "backchain" together with an application with "backchain", then we should use -Zllvm-target-feature (or a separate target modifier flag). That would however also mean that "backchain" cannot be used with the prebuilt standard library.

[uweigand]

Let me try to summarize again. This whole issue is a bit tricky as we need to consider the interaction of three distinct options: backchain, packed-stack, and soft-float. The following main principles apply:

• soft-float is a global ABI-changing option that affects interoperability. Either everything or nothing must be built with soft-float. (De facto usage: the Linux kernel uses soft-float globally, all user-space code including libraries does not use soft-float.)
• backchain does (generally) not affect interoperability You can switch between backchain and no-backchain at any function boundary, either between or within a compilation unit. However, in order to actually use the backchain for stack unwinding for debug purposes, all relevant code must be built with backchain. We consider this a "soft" requirement that's up to the user to ensure if they care about this, the compiler should not enforce anything here. (De facto usage: code by default does not use backchain, it is only enabled manually in some places that have specific debugging needs, e.g. the Linux kernel or some user-space environments like JITs where some code does not come with proper DWARF CFI.)
• packed-stack does not affect interoperability at all, and there is no observable side effect of intermixing packed and non-packed functions whatsoever. However, it is impossible to generate code using both backchain and packed-stack, unless soft-float is also in effect. This is a fully local requirement that applies on a per-function basis and must be enforced by the compiler (or else the back-end will abort with an internal error). (De facto usage: not normally used in user-space. Always used by the Linux kernel where kernel stack space is precious. Note that the kernel also uses both backchain and soft-float, so the requirement is satisfied.)

In particular I wonder what happens if some compilation units use -Ctarget-feature=+backchain, some use -Zpacked-stack, but none of them use both so the check does not get triggered.

This works fine. (With the exception that of course you will not get a reliable backtrace, as always when usage of backchain is inconsistent across the whole program.)

[fneddy]

Another thing:

backchain is used in the userspace (Ubuntu compiles everything with backchain enabled).
I dont know, and cannot find, if there is any use of packed-stackin userspace enabled by any package or distribution.