Enable non-leaf Frame Pointers for Arm64 Windows #140828
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
These commits modify compiler targets. |
|
needs rebase |
"Ugh, who else has been messing with this target?" |
|
Thanks! This is consistent with other decisions we've made for other AArch64 targets that recommend/require using frame pointers, see:
...and it obviously is what the docs want. There is an open question about how this interacts with CLI options that those PRs accidentally raised, but it will remain an open question regardless of what is done here. So, I'm just going to r+ this. @bors r+ rollup |
|
Would it be worth enabling this for Arm64 by default? Guessing that would need an MCP to discuss... |
|
Probably? Less clear to me that we need an MCP, but maybe. We don't really have "architectural defaults" in our current structure for the code. I've opened #140832 to address this for Linux platforms at least. |
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
May 9, 2025
Enable non-leaf Frame Pointers for Arm64 Windows Microsoft recommends enabling frame pointers for Arm64 Windows as it enables fast stack walking, from <https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers>: > The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack. I'm setting this to "non-leaf" as leaf functions shouldn't be spilling registers and so won't touch the frame pointer.
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
May 9, 2025
Enable non-leaf Frame Pointers for Arm64 Windows Microsoft recommends enabling frame pointers for Arm64 Windows as it enables fast stack walking, from <https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers>: > The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack. I'm setting this to "non-leaf" as leaf functions shouldn't be spilling registers and so won't touch the frame pointer.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2025
Rollup of 5 pull requests Successful merges: - rust-lang#140801 (Use span before macro expansion in lint for-loops-over-falibles) - rust-lang#140804 (add signed ints to unn- transmutes to ensure feature parity) - rust-lang#140812 (Fix `tests/rustdoc-json` triagebot message path) - rust-lang#140817 (bootstrap: more consistent use of `...` when citing configuration snippets) - rust-lang#140828 (Enable non-leaf Frame Pointers for Arm64 Windows) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2025
Rollup of 5 pull requests Successful merges: - rust-lang#140801 (Use span before macro expansion in lint for-loops-over-falibles) - rust-lang#140804 (add signed ints to unn- transmutes to ensure feature parity) - rust-lang#140812 (Fix `tests/rustdoc-json` triagebot message path) - rust-lang#140817 (bootstrap: more consistent use of `...` when citing configuration snippets) - rust-lang#140828 (Enable non-leaf Frame Pointers for Arm64 Windows) r? `@ghost` `@rustbot` modify labels: rollup --- try-job: test-various
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2025
Rollup of 5 pull requests Successful merges: - rust-lang#140801 (Use span before macro expansion in lint for-loops-over-falibles) - rust-lang#140804 (add signed ints to unn- transmutes to ensure feature parity) - rust-lang#140812 (Fix `tests/rustdoc-json` triagebot message path) - rust-lang#140817 (bootstrap: more consistent use of `...` when citing configuration snippets) - rust-lang#140828 (Enable non-leaf Frame Pointers for Arm64 Windows) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2025
Rollup merge of rust-lang#140828 - dpaoliello:arm64fp, r=workingjubilee Enable non-leaf Frame Pointers for Arm64 Windows Microsoft recommends enabling frame pointers for Arm64 Windows as it enables fast stack walking, from <https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers>: > The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack. I'm setting this to "non-leaf" as leaf functions shouldn't be spilling registers and so won't touch the frame pointer.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Microsoft recommends enabling frame pointers for Arm64 Windows as it enables fast stack walking, from https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers:
I'm setting this to "non-leaf" as leaf functions shouldn't be spilling registers and so won't touch the frame pointer.