| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Performance wise, I didn't see any hit. Numbers are in the noise. |
Sorry, something went wrong.
Documentation build overview25 files changed · ± 25 modified ± Modified |
Sorry, something went wrong.
|
Apologies.. I had to force push. |
Sorry, something went wrong.
|
|
||
| #if defined(_Py_JIT) && defined(__linux__) && defined(__ELF__) | ||
| # define PY_HAVE_JIT_GDB_UNWIND | ||
| # if defined(HAVE_EXECINFO_H) && defined(HAVE_BACKTRACE) |
There was a problem hiding this comment.
This needs a separate configure link probe. HAVE_BACKTRACE only tells us that backtrace() is available, but this code also calls libgcc-specific symbols: __register_frame and __deregister_frame.
For example, Linux builds with clang -rtlib=compiler-rt can have execinfo.h / backtrace() while those frame registration symbols are not linkable. In that case thismacro gets enabled and the build fails later at link time.
Please add a configure check for __register_frame __deregister_frame and gate PY_HAVE_JIT_GNU_BACKTRACE_UNWIND on that result.
Sorry, something went wrong.
There was a problem hiding this comment.
For example this can break in:
Sorry, something went wrong.
There was a problem hiding this comment.
ok, it makes sense.
Sorry, something went wrong.
There was a problem hiding this comment.
link probe implemented here: ef9ea52
Sorry, something went wrong.
| @support.requires_gil_enabled("test requires the GIL enabled") | ||
| @unittest.skipIf(support.is_wasi, "test not supported on WASI") | ||
| @unittest.skipUnless(sys.platform == "linux", "GNU backtrace unwinding test requires Linux") | ||
| class GnuBacktraceUnwindTests(unittest.TestCase): |
There was a problem hiding this comment.
The new test only asserts python_frames > 0 and jit_frames > 0, which a stub unwinder would pass. Two things that would help:
Sorry, something went wrong.
There was a problem hiding this comment.
Addressed here: 01df239
Sorry, something went wrong.
| * A NULL result is valid when publication succeeded only through backends | ||
| * with no unregister step, such as perf map output. | ||
| */ | ||
| _PyJitCodeRegistration *_PyJit_RegisterCode(const void *code_addr, |
There was a problem hiding this comment.
_PyJit_RegisterCode returns NULL for three different reasons (perf-only success, calloc failure, all backends failed) and the caller can't tell them apart. Could you rename registered -> any_registered and add a one-liner near the perf branch noting it's intentionally not counted? The deleted comment from jit_record_code about partial-failure being non-fatal would also be nice to restore.
Sorry, something went wrong.
There was a problem hiding this comment.
Addressed here: cf16da0
Sorry, something went wrong.
| #if defined(PY_HAVE_JIT_GDB_UNWIND) \ | ||
| || defined(PY_HAVE_JIT_GNU_BACKTRACE_UNWIND) | ||
| struct _PyJitCodeRegistration { | ||
| # if defined(PY_HAVE_JIT_GDB_UNWIND) |
There was a problem hiding this comment.
Do we really need to guard every field of the struct?
Sorry, something went wrong.
There was a problem hiding this comment.
The current version is valid, but the per-field guards are probably more defensive than necessary. I added them to keep the registration object matching the enabled backends, but since the struct is private and the fields are opaque handles, we can simplify the struct and keep the feature guards around the actual register/unregister code.
Sorry, something went wrong.
There was a problem hiding this comment.
I reviewed this and tested it locally again and it works in all cases I can find.
Great work @diegorusso 💪
Sorry, something went wrong.
⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️Hi! The buildbot s390x RHEL9 LTO + PGO 3.x (tier-3) has failed when building commit 1e5d942. What do you need to do:
You can take a look at the buildbot page here: https://buildbot.python.org/#/builders/1578/builds/4764 Failed tests:
Failed subtests:
Summary of the results of the build (if available): == Click to see traceback logsTraceback (most recent call last):
File "/var/lib/buildbot/worker/cstratak-rhel9-s390x/3.x.cstratak-rhel9-s390x.lto-pgo/build/Lib/test/test_frame_pointer_unwind.py", line 241, in test_manual_unwind_respects_frame_pointers
self.assertGreaterEqual(
~~~~~~~~~~~~~~~~~~~~~~~^
python_frames,
^^^^^^^^^^^^^^
STACK_DEPTH,
^^^^^^^^^^^^
f"expected to find Python frames on {self.machine} with env {env}",
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
AssertionError: 1 not greater than or equal to 10 : expected to find Python frames on s390x with env {'PYTHON_JIT': '0'}
|
Sorry, something went wrong.
|
The buildbot failure will be fixed by: #149362 |
Sorry, something went wrong.
|
Looks like this fails on ppc64le: https://buildbot.python.org/#/builders/451/builds/6989 |
Sorry, something went wrong.
|
Also Raspbian failures went from {"length": 1, "python_frames": 0, "jit_frames": 0, "other_frames": 1, "jit_backend": null}
to {"length": 0, "python_frames": 0, "jit_frames": 0, "other_frames": 0, "jit_backend": null, "unwinder": "gnu_backtrace_unwind"}
(even with #149362 applied) |
Sorry, something went wrong.
No, the GNU backtrace works on that platform. The one failing is test.test_frame_pointer_unwind.FramePointerUnwindTests.test_manual_unwind_respects_frame_pointers and very likely because the way we walk the fp chain. We need to update @pablogsal PR (#149362) to include the shape for ppc64. |
Sorry, something went wrong.
|
ppc64le is fixed now; but on Raspbian it is GNU backtrace that's failing -- see #149409 (comment) |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
📚 Documentation preview 📚: https://cpython-previews--149104.org.readthedocs.build/