user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

encode compiler team acceptance of -Cforce-frame-pointers change

Browse source
This commit is contained in:
Jubilee Young 2024-05-15 23:47:48 -07:00
parent a6b62d893f
commit e57b4b19e8
1 changed files with 30 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

35
tests/codegen/frame-pointer-cli-control.rs
View file

@ -8,14 +8,37 @@
//@ [aarch64-apple-on] compile-flags: --target=aarch64-apple-darwin -Cforce-frame-pointers=on
//@ [aarch64-apple-off] needs-llvm-components: aarch64
//@ [aarch64-apple-off] compile-flags: --target=aarch64-apple-darwin -Cforce-frame-pointers=off
/*
Tests that the frame pointers can be controlled by the CLI. We find aarch64-apple-darwin useful
because of its icy-clear policy regarding frame pointers (software SHALL be compiled with them),
e.g. https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms says:
/*!
Tests the extent to which frame pointers can be controlled by the CLI.
The behavior of our frame pointer options, at present, is an irreversible ratchet, where
a "weaker" option that allows omitting frame pointers may be overridden by the target demanding
that all code (or all non-leaf code, more often) must be compiled with frame pointers.
This was discussed on 2025-05-22 in the T-compiler meeting and accepted as an intentional change,
ratifying the prior decisions by compiler contributors and reviewers as correct,
though it was also acknowledged that the flag allows somewhat confusing inputs.
We find aarch64-apple-darwin useful because of its icy-clear policy regarding frame pointers,
e.g. <https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms> says:
* The frame pointer register (x29) must always address a valid frame record. Some functions —
such as leaf functions or tail calls — may opt not to create an entry in this list.
As a result, stack traces are always meaningful, even without debug information.
Many Rust fn, if externally visible, may be expected to follow target ABI by tools or asm code!
This can make it a problem to generate ABI-incorrect code, which may mean "with frame pointers".
For this and other reasons, `-Cforce-frame-pointers=off` cannot override the target definition.
This can cause some confusion because it is "reverse polarity" relative to C compilers, which have
commands like `-fomit-frame-pointer`, `-fomit-leaf-frame-pointer`, or `-fno-omit-frame-pointer`!
Specific cases where platforms or tools rely on frame pointers for sound or correct unwinding:
- illumos: <https://smartos.org/bugview/OS-7515>
- aarch64-windows: <https://github.com/rust-lang/rust/issues/123686>
- aarch64-linux: <https://github.com/rust-lang/rust/issues/123733>
- dtrace (freebsd and openbsd): <https://github.com/rust-lang/rust/issues/97723>
- openbsd: <https://github.com/rust-lang/rust/issues/43575>
- i686-msvc <https://github.com/rust-lang/backtrace-rs/pull/584#issuecomment-1966177530>
- i686-mingw: <https://github.com/rust-lang/rust/commit/3f1d3948d6d434b34dd47f132c126a6cb6b8a4ab>
*/
#![feature(no_core, lang_items)]
#![no_core]
@ -32,5 +55,7 @@ pub fn peach(x: u32) -> u32 {
// force-on-SAME: {{.*}}"frame-pointer"="all"
// aarch64-apple-SAME: {{.*}}"frame-pointer"="non-leaf"
// aarch64-apple-on-SAME: {{.*}}"frame-pointer"="all"
// aarch64-apple-off-NOT: {{.*}}"frame-pointer"{{.*}}
//
// yes, we are testing this doesn't do anything:
// aarch64-apple-off-SAME: {{.*}}"frame-pointer"="non-leaf"
// CHECK-SAME: }