Skip to content

Conversation

savannahostrowski
Copy link
Member

@savannahostrowski savannahostrowski commented Oct 19, 2025

Alright, this took me longer than expected for two reasons:

  • Bumping to LLVM 20 required some changes to the infrastructure we use to grab LLVM as a dependency on Windows. As of 20, LLVM now contains files that exceed GitHub's allowable size, so checking these directly into cpython-bin-deps' tree was not an option. Instead, this PR adds the ability to pull from release artifacts (see https://github.com/python/cpython-bin-deps/releases/tag/llvm-20.1.8.0). This also makes the process of bumping LLVM for Windows a little less hairy. Thank you, @emmatyping, for much of this code, and thank you, @zware, for publishing the release artifact for me 🙏 !

  • For macOS x86_64 debug builds, external symbol references generated by LLVM 20 can exceed the ±2GB PC-relative addressing range that patch_32r requires. This manifested as assertion failures in free-threading tests (see https://github.com/savannahostrowski/cpython/actions/runs/18438327725/job/52537027963?pr=10 as an example). After going down a rabbit hole, I believe the correct fix here is to implement x86_64 trampolines (similar to our existing aarch64 implementation) to handle out-of-range symbols...and so I've done that. AFAICT, trampolines are only needed on macOS right now, as the other target platforms have different relocation mechanisms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants