-
Notifications
You must be signed in to change notification settings - Fork 13.3k
aarch64-linux: Default to FramePointer::NonLeaf #140832
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
aarch64-linux: Default to FramePointer::NonLeaf #140832
Conversation
1af6325
to
fbaf582
Compare
@bors try |
⌛ Trying commit fbaf582 with merge b5f9a0d36e6b3537b76a5aa710e1d5d13313f3d1... |
…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
This comment has been minimized.
This comment has been minimized.
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.
fbaf582
to
89ad6c3
Compare
@bors try |
…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
cc re: OpenHarmony: @Amanieu @lubinglun I assume there's no objections to doing this? I can revert the change for your particular aarch64-linux targets if you want. |
This comment was marked as outdated.
This comment was marked as outdated.
No specific objection for OpenHarmony, though I have a more general objection.
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:
|
@Amanieu What authority would you defer to? Who is gonna specify that requirement? Should we ask Linus Torvalds? |
The aarch64-unknown-linux-gnu target was Unless we intend to remove the aarch64-unknown-linux-gnu target, I suppose, but that would make people much more mad. |
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. |
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") |
☀️ Try build successful - checks-actions |
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.
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