-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
gh-136541: Fix several problems of perf trampolines in x86_64 and aarch64 #136500
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
Conversation
🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 8b228c0 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F136500%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
!buildbot perf |
🤖 New build scheduled with the buildbot fleet by @pablogsal for commit b174fe8 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F136500%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Do you think it's possible to remove this skipUnless
now?
cpython/Lib/test/test_perf_profiler.py
Lines 407 to 410 in d754f75
@unittest.skipUnless( | |
is_unwinding_reliable_with_frame_pointers(), | |
"Unwinding is unreliable with frame pointers", | |
) |
(also I think there is a typo in that string. Probably was meant to say "Unwinding is unreliable without frame pointers".)
I don't think we can. I am pretty sure Perf will still choke without frame pointers in the outer functions and fail the test. The sentence is indeed confusing but is trying to say that unwinding using frame pointers is unreliable as "not working" |
@canova I am AFK do you mind checking in case we are lucky? |
Ah that's right. If we add a test with |
Just did, and unfortunately, we are not lucky :') still fails. |
Added the same comment to the other PR, but adding here for posterity: Tested this PR using samply. I can verify that it fixes the stack walking! Here are before and after profiles: |
!buildbot Perf |
🤖 New build scheduled with the buildbot fleet by @pablogsal for commit b174fe8 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F136500%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
Thank you for making this change! If the Python C code is compiled with framepointers, I believe this change will also improve unwinding when you use Linux Oh, and one other thing I want to mention: samply supports both macOS and Linux, and this patch helps with both, so it's not strictly related to just #136459. |
The profiles that I captured were actually from Linux x86_64. I should have mentioned that too :) |
It does not unfortunately. See #136500 (comment) and #136500 (review) |
it chokes on it and stops at that frame (like any other unwinder on the landscape) :S We are having that problem here for the big JIT and is a real pain: #126910 |
!buildbot Fedora Stable |
🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 8a81457 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F136500%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
…nd aarch64 (pythonGH-136500) This commit fixes the following problems: * The x86_64 trampolines are not preserving frame pointers * The hardcoded offsets to the code segment from the FDE only worked properly for x64_64 * The CIE data was not following conventions of aarch64 * The eh_frame for aarch64 was not fully correct (cherry picked from commit 236f733) Co-authored-by: Pablo Galindo Salgado <[email protected]>
Sorry, @pablogsal, I could not cleanly backport this to
|
GH-136544 is a backport of this pull request to the 3.14 branch. |
…86_64 and aarch64 (pythonGH-136500) This commit fixes the following problems: * The x86_64 trampolines are not preserving frame pointers * The hardcoded offsets to the code segment from the FDE only worked properly for x64_64 * The CIE data was not following conventions of aarch64 * The eh_frame for aarch64 was not fully correct (cherry picked from commit 236f733) Co-authored-by: Pablo Galindo Salgado <[email protected]>
GH-136545 is a backport of this pull request to the 3.13 branch. |
…and aarch64 (GH-136500) (#136545) This commit fixes the following problems: * The x86_64 trampolines are not preserving frame pointers * The hardcoded offsets to the code segment from the FDE only worked properly for x64_64 * The CIE data was not following conventions of aarch64 * The eh_frame for aarch64 was not fully correct (cherry picked from commit 236f733)
…and aarch64 (GH-136500) (#136544) gh-136541: Fix several problems of perf trampolines in x86_64 and aarch64 (GH-136500) This commit fixes the following problems: * The x86_64 trampolines are not preserving frame pointers * The hardcoded offsets to the code segment from the FDE only worked properly for x64_64 * The CIE data was not following conventions of aarch64 * The eh_frame for aarch64 was not fully correct (cherry picked from commit 236f733) Co-authored-by: Pablo Galindo Salgado <[email protected]>
…nd aarch64 (python#136500) This commit fixes the following problems: * The x86_64 trampolines are not preserving frame pointers * The hardcoded offsets to the code segment from the FDE only worked properly for x64_64 * The CIE data was not following conventions of aarch64 * The eh_frame for aarch64 was not fully correct
Fix the following problems: