aarch64-linux: Default to FramePointer::NonLeaf #140832

workingjubilee · 2025-05-08T21:52:04Z

For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements:

Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets also use non-leaf frame pointers. This reflects what compilers like clang do.

workingjubilee · 2025-05-08T21:58:33Z

@bors try

bors · 2025-05-08T21:59:43Z

⌛ Trying commit fbaf582 with merge b5f9a0d...

…use-frame-pointers, r=<try> aarch64-linux: Default to FramePointer::NonLeaf For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements: - Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers - Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers - AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets also use non-leaf frame pointers. r? ghost try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: arm-android try-job: armhf-gnu try-job: dist-aarch64-linux try-job: dist-ohos try-job: test-various

workingjubilee · 2025-05-08T22:44:31Z

@bors try

bors · 2025-05-08T22:45:40Z

⌛ Trying commit 89ad6c3 with merge 08309a2...

…use-frame-pointers, r=<try> aarch64-linux: Default to FramePointer::NonLeaf For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements: - Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers - Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers - AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets also use non-leaf frame pointers. r? ghost try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: arm-android try-job: armhf-gnu try-job: dist-aarch64-linux try-job: dist-ohos try-job: test-various

workingjubilee · 2025-05-08T22:47:17Z

cc re: OpenHarmony: @Amanieu @lubinglun
cc re: Android: @chriswailes @maurer @mgeisler

I assume there's no objections to doing this? I can revert the change for your particular aarch64-linux targets if you want.

Amanieu · 2025-05-08T23:26:24Z

I assume there's no objections to doing this? I can revert the change for your particular aarch64-linux targets if you want.

No specific objection for OpenHarmony, though I have a more general objection.

For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements:

While this is required on Windows & Apple as per their docs, Linux doesn't actually specify whether a frame pointer is required and I would assume the default assumption is that it isn't since that is the default setting on GCC for aarch64-linux.

AAPCS64 explicitly allows this as an option:

It may elect not to maintain a frame chain and to use the frame pointer register as a general-purpose callee-saved register.

workingjubilee · 2025-05-08T23:28:35Z

@Amanieu What authority would you defer to? Who is gonna specify that requirement? Should we ask Linus Torvalds?

workingjubilee · 2025-05-08T23:34:12Z

The aarch64-unknown-linux-gnu target was ~~added~~ raised to tier 1 at the behest of Arm, so if you don't have an answer to that, then the answer is the buck stops either with us or with Arm. We can add more process to this decision for an MCP or something, to see if we have a consensus for ourselves on what we should do, but "the platform is allowed to specify something other than maximal conformance" must not be allowed to combine with "no one decides because the definition of who 'owns' the platform is ambiguous" to result in "Rust chooses inaction".

Unless we intend to remove the aarch64-unknown-linux-gnu target, I suppose, but that would make people much more mad.

Amanieu · 2025-05-08T23:37:04Z

Actually I just checked and it seems that I am incorrect: the default on AArch64 Linux for both GCC and Clang is to enable frame pointers for non-leaf functions. I withdraw my objection.

Regarding authority, the target owner is Arm so they get the final say. However I would imagine that they would want to match the behavior of C compilers which they also contribute to.

workingjubilee · 2025-05-08T23:38:00Z

Ah, well, yes, I would agree, I just figured the answer from Arm was the obvious one ("it puts the frame pointer in the register or else it gets the hose again")

bors · 2025-05-09T01:55:18Z

☀️ Try build successful - checks-actions
Build commit: 08309a2 (08309a214d769a277a7ecc5287b9a39fc71006b6)

rustbot · 2025-05-17T04:38:53Z

These commits modify compiler targets.
(See the Target Tier Policy.)

workingjubilee · 2025-05-17T04:39:25Z

~~ah bother, merge conflicts~~ easily resolved

workingjubilee · 2025-05-17T04:41:52Z

r? compiler

For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements: - Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers - Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers - AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets use non-leaf frame pointers. This reflects what compilers like clang do.

compiler-errors · 2025-05-22T09:34:05Z

@bors r+

bors · 2025-05-22T09:34:07Z

📌 Commit 0c157b5 has been approved by compiler-errors

It is now in the queue for this repository.

…d-use-frame-pointers, r=compiler-errors aarch64-linux: Default to FramePointer::NonLeaf For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements: - Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers - Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers - AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets also use non-leaf frame pointers. This reflects what compilers like clang do.

Rollup of 7 pull requests Successful merges: - #138896 (std: fix aliasing bug in UNIX process implementation) - #140832 (aarch64-linux: Default to FramePointer::NonLeaf) - #141065 (Updated std doctests for wasm) - #141369 (Simplify `format_integer_with_underscore_sep`) - #141374 (make shared_helpers exe function work for both cygwin and non-cygwin hosts) - #141398 (chore: fix typos in comment) - #141457 (Update mdbook to 0.4.50) Failed merges: - #141405 (GetUserProfileDirectoryW is now documented to always store the size) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #140832 - workingjubilee:aarch64-linux-should-use-frame-pointers, r=compiler-errors aarch64-linux: Default to FramePointer::NonLeaf For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements: - Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers - Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers - AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets also use non-leaf frame pointers. This reflects what compilers like clang do.

See rust-lang/rust#140832. This reverts commit 75ec0b6.

See rust-lang/rust#140832. This reverts commit 75ec0b6. Part-of: <https://gitlab.gnome.org/GNOME/snapshot/-/merge_requests/406>

Pkgsrc changes: * Adjust patches to adapt to upstream changes and new versions. * assosicated checksums Upstream changes relative to 1.88.0: Version 1.89.0 (2025-08-07) ========================== Language -------- - [Stabilize explicitly inferred const arguments (`feature(generic_arg_infer)`)] (rust-lang/rust#141610) - [Add a warn-by-default `mismatched_lifetime_syntaxes` lint.] (rust-lang/rust#138677) This lint detects when the same lifetime is referred to by different syntax categories between function arguments and return values, which can be confusing to read, especially in unsafe code. This lint supersedes the warn-by-default `elided_named_lifetimes` lint. - [Expand `unpredictable_function_pointer_comparisons` to also lint on function pointer comparisons in external macros] (rust-lang/rust#134536) - [Make the `dangerous_implicit_autorefs` lint deny-by-default] (rust-lang/rust#141661) - [Stabilize the avx512 target features] (rust-lang/rust#138940) - [Stabilize `kl` and `widekl` target features for x86] (rust-lang/rust#140766) - [Stabilize `sha512`, `sm3` and `sm4` target features for x86] (rust-lang/rust#140767) - [Stabilize LoongArch target features `f`, `d`, `frecipe`, `lasx`, `lbt`, `lsx`, and `lvz`] (rust-lang/rust#135015) - [Remove `i128` and `u128` from `improper_ctypes_definitions`] (rust-lang/rust#137306) - [Stabilize `repr128` (`#[repr(u128)]`, `#[repr(i128)]`)] (rust-lang/rust#138285) - [Allow `#![doc(test(attr(..)))]` everywhere] (rust-lang/rust#140560) - [Extend temporary lifetime extension to also go through tuple struct and tuple variant constructors] (rust-lang/rust#140593) Compiler -------- - [Default to non-leaf frame pointers on aarch64-linux] (rust-lang/rust#140832) - [Enable non-leaf frame pointers for Arm64EC Windows] (rust-lang/rust#140862) - [Set Apple frame pointers by architecture] (rust-lang/rust#141797) Platform Support ---------------- - [Add new Tier-3 targets `loongarch32-unknown-none` and `loongarch32-unknown-none-softfloat`] (rust-lang/rust#142053) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html Libraries --------- - [Specify the base path for `file!`] (rust-lang/rust#134442) - [Allow storing `format_args!()` in a variable] (rust-lang/rust#140748) - [Add `#[must_use]` to `[T; N]::map`] (rust-lang/rust#140957) - [Implement `DerefMut` for `Lazy{Cell,Lock}`] (rust-lang/rust#129334) - [Implement `Default` for `array::IntoIter`] (rust-lang/rust#141574) - [Implement `Clone` for `slice::ChunkBy`] (rust-lang/rust#138016) - [Implement `io::Seek` for `io::Take`] (rust-lang/rust#138023) Stabilized APIs --------------- - [`NonZero<char>`] (https://doc.rust-lang.org/stable/std/num/struct.NonZero.html) - Many intrinsics for x86, not enumerated here - [AVX512 intrinsics](rust-lang/rust#111137) - [`SHA512`, `SM3` and `SM4` intrinsics] (rust-lang/rust#126624) - [`File::lock`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock) - [`File::lock_shared`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock_shared) - [`File::try_lock`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.try_lock) - [`File::try_lock_shared`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.try_lock_shared) - [`File::unlock`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.unlock) - [`NonNull::from_ref`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.from_ref) - [`NonNull::from_mut`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.from_mut) - [`NonNull::without_provenance`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.without_provenance) - [`NonNull::with_exposed_provenance`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.with_exposed_provenance) - [`NonNull::expose_provenance`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.expose_provenance) - [`OsString::leak`] (https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.leak) - [`PathBuf::leak`] (https://doc.rust-lang.org/stable/std/path/struct.PathBuf.html#method.leak) - [`Result::flatten`] (https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.flatten) - [`std::os::linux::net::TcpStreamExt::quickack`] (https://doc.rust-lang.org/stable/std/os/linux/net/trait.TcpStreamExt.html#tymethod.quickack) - [`std::os::linux::net::TcpStreamExt::set_quickack`] (https://doc.rust-lang.org/stable/std/os/linux/net/trait.TcpStreamExt.html#tymethod.set_quickack) These previously stable APIs are now stable in const contexts: - [`<[T; N]>::as_mut_slice`] (https://doc.rust-lang.org/stable/std/primitive.array.html#method.as_mut_slice) - [`<[u8]>::eq_ignore_ascii_case`] (https://doc.rust-lang.org/stable/std/primitive.slice.html#impl-%5Bu8%5D/method.eq_ignore_ascii_case) - [`str::eq_ignore_ascii_case`] (https://doc.rust-lang.org/stable/std/primitive.str.html#impl-str/method.eq_ignore_ascii_case) Cargo ----- - [`cargo fix` and `cargo clippy --fix` now default to the same Cargo target selection as other build commands.] (rust-lang/cargo#15192) Previously it would apply to all targets (like binaries, examples, tests, etc.). The `--edition` flag still applies to all targets. - [Stabilize doctest-xcompile.] (rust-lang/cargo#15462) Doctests are now tested when cross-compiling. Just like other tests, it will use the [`runner` setting] (https://doc.rust-lang.org/cargo/reference/config.html#targettriplerunner) to run the tests. If you need to disable tests for a target, you can use the [ignore doctest attribute] (https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html#ignoring-targets) to specify the targets to ignore. Rustdoc ----- - [On mobile, make the sidebar full width and linewrap] (rust-lang/rust#139831). This makes long section and item names much easier to deal with on mobile. Compatibility Notes ------------------- - [Make `missing_fragment_specifier` an unconditional error] (rust-lang/rust#128425) - [Enabling the `neon` target feature on `aarch64-unknown-none-softfloat` causes a warning] (rust-lang/rust#135160) because mixing code with and without that target feature is not properly supported by LLVM - [Sized Hierarchy: Part I](rust-lang/rust#137944) - Introduces a small breaking change affecting `?Sized` bounds on impls on recursive types which contain associated type projections. It is not expected to affect any existing published crates. Can be fixed by refactoring the involved types or opting into the `sized_hierarchy` unstable feature. See the [FCP report] (rust-lang/rust#137944 (comment)) for a code example. - The warn-by-default `elided_named_lifetimes` lint is [superseded by the warn-by-default `mismatched_lifetime_syntaxes` lint.] (rust-lang/rust#138677) - [Error on recursive opaque types earlier in the type checker] (rust-lang/rust#139419) - [Type inference side effects from requiring element types of array repeat expressions are `Copy` are now only available at the end of type checking] (rust-lang/rust#139635) - [The deprecated accidentally-stable `std::intrinsics::{copy,copy_nonoverlapping,write_bytes}` are now proper intrinsics] (rust-lang/rust#139916). There are no debug assertions guarding against UB, and they cannot be coerced to function pointers. - [Remove long-deprecated `std::intrinsics::drop_in_place`] (rust-lang/rust#140151) - [Make well-formedness predicates no longer coinductive] (rust-lang/rust#140208) - [Remove hack when checking impl method compatibility] (rust-lang/rust#140557) - [Remove unnecessary type inference due to built-in trait object impls] (rust-lang/rust#141352) - [Lint against "stdcall", "fastcall", and "cdecl" on non-x86-32 targets] (rust-lang/rust#141435) - [Future incompatibility warnings relating to the never type (`!`) are now reported in dependencies] (rust-lang/rust#141937) - [Ensure `std::ptr::copy_*` intrinsics also perform the static self-init checks] (rust-lang/rust#142575) Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Correctly un-remap compiler sources paths with the `rustc-dev` component] (rust-lang/rust#142377)

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 8, 2025

workingjubilee force-pushed the aarch64-linux-should-use-frame-pointers branch from 1af6325 to fbaf582 Compare May 8, 2025 21:58

This comment has been minimized.

Sign in to view

workingjubilee force-pushed the aarch64-linux-should-use-frame-pointers branch from fbaf582 to 89ad6c3 Compare May 8, 2025 22:44

workingjubilee mentioned this pull request May 8, 2025

Enable non-leaf Frame Pointers for Arm64 Windows #140828

Merged

This comment was marked as outdated.

Sign in to view

workingjubilee marked this pull request as ready for review May 17, 2025 04:38

workingjubilee force-pushed the aarch64-linux-should-use-frame-pointers branch from 89ad6c3 to a4d6303 Compare May 17, 2025 04:41

rustbot assigned compiler-errors May 17, 2025

workingjubilee force-pushed the aarch64-linux-should-use-frame-pointers branch from a4d6303 to 0c157b5 Compare May 17, 2025 04:43

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 22, 2025

This was referenced May 23, 2025

Rollup of 4 pull requests #141462

Closed

Rollup of 7 pull requests #141463

Merged

bors merged commit d6a61da into rust-lang:master May 23, 2025
6 checks passed

rustbot added this to the 1.89.0 milestone May 23, 2025

workingjubilee deleted the aarch64-linux-should-use-frame-pointers branch June 23, 2025 21:36

workingjubilee mentioned this pull request Jun 23, 2025

Create rustc_target::spec::Target from a Builder rust-lang/compiler-team#890

Closed

3 tasks

workingjubilee added the relnotes Marks issues that should be documented in the release notes of the next release. label Jun 27, 2025

rustbot mentioned this pull request Jun 27, 2025

Tracking issue for release notes of #140832: aarch64-linux: Default to FramePointer::NonLeaf #143100

Open

cuviper mentioned this pull request Jul 17, 2025

Draft release notes for 1.89.0 #144097

Closed

gnomesysadmins pushed a commit to GNOME/snapshot that referenced this pull request Aug 7, 2025

Revert "flatpak: Build with force-frame-pointers"

3be385c

See rust-lang/rust#140832. This reverts commit 75ec0b6.

gnomesysadmins pushed a commit to GNOME/snapshot that referenced this pull request Aug 7, 2025

Revert "flatpak: Build with force-frame-pointers"

2aabd60

See rust-lang/rust#140832. This reverts commit 75ec0b6. Part-of: <https://gitlab.gnome.org/GNOME/snapshot/-/merge_requests/406>

aarch64-linux: Default to FramePointer::NonLeaf #140832

aarch64-linux: Default to FramePointer::NonLeaf #140832

Uh oh!

Conversation

workingjubilee commented May 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee commented May 8, 2025

Uh oh!

bors commented May 8, 2025

Uh oh!

This comment has been minimized.

workingjubilee commented May 8, 2025

Uh oh!

bors commented May 8, 2025

Uh oh!

workingjubilee commented May 8, 2025

Uh oh!

This comment was marked as outdated.

Amanieu commented May 8, 2025

Uh oh!

workingjubilee commented May 8, 2025

Uh oh!

workingjubilee commented May 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Amanieu commented May 8, 2025

Uh oh!

workingjubilee commented May 8, 2025

Uh oh!

bors commented May 9, 2025

Uh oh!

rustbot commented May 17, 2025

Uh oh!

workingjubilee commented May 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee commented May 17, 2025

Uh oh!

compiler-errors commented May 22, 2025

Uh oh!

bors commented May 22, 2025

Uh oh!

Uh oh!

Uh oh!

workingjubilee commented May 8, 2025 •

edited

Loading

workingjubilee commented May 8, 2025 •

edited

Loading

workingjubilee commented May 17, 2025 •

edited

Loading