gh-151666: Avoid LLVM libunwind bad-FDE warning for JIT frame registration.#151667
Open
DEVwXZ4Njdmo4hm wants to merge 1 commit into
Open
gh-151666: Avoid LLVM libunwind bad-FDE warning for JIT frame registration.#151667DEVwXZ4Njdmo4hm wants to merge 1 commit into
DEVwXZ4Njdmo4hm wants to merge 1 commit into
Conversation
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
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
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.
This is a cautious reference patch for a warning I hit while experimenting with
CPython's JIT using newer LLVM/Clang toolchains.
CPython currently documents LLVM 21 as the officially supported LLVM version for
building the JIT. The issue described here was observed with LLVM 22.1.8 and
LLVM main
564e83191cc5686429cefe69aff81c2aeb268f5a(23.0.0git), so I do notwant to present this as a request to expand the supported LLVM range. I am
opening this mainly to share the root cause and a possible small compatibility
patch, and I would appreciate maintainers taking a careful look at whether this
is appropriate for CPython.
When a JIT executor is published for GNU
backtrace()unwinding, CPython buildsa small
.eh_framebuffer containing a CIE, an FDE, and a zero-lengthterminator. The current GNU backtrace registration path passes the start of that
buffer to
__register_frame(). That matches GCC libgcc's behavior: libgcc walksan
.eh_framesection and skips from the CIE to the FDE.LLVM libunwind 22 and 23 expose the same
__register_frame()symbol, but theirimplementation treats the argument as a single FDE address. If CPython passes the
start of the
.eh_framebuffer, LLVM libunwind sees the CIE first and prints:I confirmed that passing the first FDE address avoids the warning with LLVM
libunwind 22 and 23. The same local check also showed that GCC libgcc continues
to accept the original
.eh_framesection-start registration.The patch takes a narrow approach:
deregister the first FDE instead of the
.eh_framesection start;.eh_framebase pointer in a small registration handle soteardown still frees the correct allocation;
path;
appears in the GNU backtrace unwind helper's stderr.
The version guard is intentionally conservative. It follows the toolchain range
where I reproduced and verified the warning, and it avoids changing behavior for
LLVM 21, which remains CPython's documented JIT dependency. That said, this is
only a compiler-version guard; it is not a runtime probe for the actual unwinder
implementation. If maintainers prefer a configure-time/runtime capability check,
or if this should be handled in a different layer, I am happy to rework the
patch.
Validation performed:
bfecfcc2a860071c8e5022ac512bde94e0fb5f76(3.16.0a0)3.15.0b222.1.8564e83191cc5686429cefe69aff81c2aeb268f5a(23.0.0git)In those local builds, the warning disappeared with the patch applied.