Choco is lagging here and only has 21.1.0, so I'm on the fence about keeping this in the README, especially given how prominently the LLVM releases page now features installers for Windows.

Copy link

Contributor

diegorusso commentedNov 4, 2025

Well, here's a fun treat...looks like the logic to fetch the LLVM binary as a release artifact fromhttps://github.com/python/cpython-bin-deps/releases/tag/llvm-21.1.4.0 never actually worked 😓. CI only passed for Windows on#140329 because LLVM 20 is included in the base image we use for Windows builds (seehttps://github.com/actions/partner-runner-images/blob/main/images/arm-windows-11-image.md#language-and-runtime).
This PR patches up the logic for extracting the tarball inget_externals.py and then...just bumps the version to 21.
Issue:Update JIT builds to use LLVM 21 #140479

What about the Windows x86_64 image? Does it have llvm 20 as well?

Also, in this PR we do 2 things: fix some logic and bump to 21. Wouldn't it be better to do 2 PRs? In case we need to revert to llvm 20 (for any reason) we will revert to a working fetching for version 20.

savannahostrowski mentioned this pull request

Nov 4, 2025

GH-136895: Fixes for pulling LLVM as a release artifact#141002

Merged

Remove fixes for Windows release artifacts

ef52c5a

Copy link

MemberAuthor

savannahostrowski commentedNov 4, 2025

@diegorusso Same deal with x86_64 - seehttps://github.com/actions/runner-images/blob/win22/20251021.76/images/windows/Windows2022-Readme.md#language-and-runtime

Sure - see#141002

diegorusso approved these changes

Nov 4, 2025

View reviewed changes

Copy link

Contributor

diegorusso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Provided#141002 gets merged before, this can go in as well. Thanks for splitting them up.

bedevere-appbot added awaiting merge and removed awaiting core review labels

Nov 4, 2025

Merge branch 'main' into llvm-21

9778bdd

Fidget-Spinner approved these changes

Nov 7, 2025

View reviewed changes

Copy link

Member

Fidget-Spinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Looks simple enough, let's do this!

Copy link

Member

pablogsal commentedNov 9, 2025•
edited
Loading

I have tried to rebasehttps://github.com/pablogsal/cpython-unwind to check the unwinding. Looks like the function to test now needs to be more complicated beause the JIT refuses to call functions if there are branches now and requires tons of iterations to start jitting. I would love if someone can take a look atrun.py. With the code we can validate all unwinding methods

Copy link

Member

Fidget-Spinner commentedNov 9, 2025•
edited
Loading

The main branch's JIT doesn't seem to want to compile the example due to trace stack underflow. So I reduced the side exit count on my tracing JIT example and tried. Seems like LLVM 21 doesn't fix the problem :(

PYTHON_JIT=0-----------Testing various unwinding methods on the same deep call stack...[GNU backtrace]Total frames: 27Showing first 10 frames:  # 0  /home/ken/Documents/GitHub/cpython-unwind/stackunwind.cpython-315-x86_64-linux-gnu.so(+0x280a) [0x78674f7a580a]  # 1  ../cpython/python(PyObject_Vectorcall+0x33) [0x58c0e08d2303]  # 2  ../cpython/python(_PyEval_EvalFrameDefault+0xf7a1) [0x58c0e086b141]  # 3  ../cpython/python(+0x2860aa) [0x58c0e0a430aa]  # 4  ../cpython/python(PyObject_Vectorcall+0x33) [0x58c0e08d2303]  # 5  ../cpython/python(_PyEval_EvalFrameDefault+0x3fb3) [0x58c0e085f953]  # 6  ../cpython/python(+0x2860aa) [0x58c0e0a430aa]  # 7  ../cpython/python(PyObject_Vectorcall+0x33) [0x58c0e08d2303]  # 8  ../cpython/python(_PyEval_EvalFrameDefault+0x3fb3) [0x58c0e085f953]  # 9  ../cpython/python(+0x2860aa) [0x58c0e0a430aa]  ... (17 more frames)[libunwind]Total frames: 26Showing first 10 frames:  # 0  PyObject_Vectorcall+0x33  # 1  _PyEval_EvalFrameDefault+0xf7a1  # 2  _PyEval_Vector+0x21a  # 3  PyObject_Vectorcall+0x33  # 4  _PyEval_EvalFrameDefault+0x3fb3  # 5  _PyEval_Vector+0x21a  # 6  PyObject_Vectorcall+0x33  # 7  _PyEval_EvalFrameDefault+0x3fb3  # 8  _PyEval_Vector+0x21a  # 9  PyObject_Vectorcall+0x33  ... (16 more frames)[libdw (DWARF)]Total frames: 26Showing first 10 frames:  # 0  PyObject_Vectorcall  # 1  _PyEval_EvalFrameDefault  # 2  _PyEval_Vector  # 3  PyObject_Vectorcall  # 4  _PyEval_EvalFrameDefault  # 5  _PyEval_Vector  # 6  PyObject_Vectorcall  # 7  _PyEval_EvalFrameDefault  # 8  _PyEval_Vector  # 9  PyObject_Vectorcall  ... (16 more frames)[Manual frame pointers]Total frames: 4Showing first 4 frames:  # 0  0x58c0e08d2303  # 1  0x2  # 2  0x58c0e0dbb7e0  # 3  0x2PYTHON_JIT=1------------[GNU backtrace]Total frames: 6Showing first 6 frames:  # 0  /home/ken/Documents/GitHub/cpython-unwind/stackunwind.cpython-315-x86_64-linux-gnu.so(+0x280a) [0x7a0a357d080a]  # 1  ../cpython/python(PyObject_Vectorcall+0x33) [0x57385e3d3303]  # 2  ../cpython/python(_PyEval_EvalFrameDefault+0xf7a1) [0x57385e36c141]  # 3  ../cpython/python(+0x2860aa) [0x57385e5440aa]  # 4  ../cpython/python(PyObject_Vectorcall+0x33) [0x57385e3d3303]  # 5  [0x7a0a3398d4fb][libunwind]Total frames: 5Showing first 5 frames:  # 0  PyObject_Vectorcall+0x33  # 1  _PyEval_EvalFrameDefault+0xf7a1  # 2  _PyEval_Vector+0x21a  # 3  PyObject_Vectorcall+0x33  # 4  <unknown>[libdw (DWARF)]Total frames: 5Showing first 5 frames:  # 0  PyObject_Vectorcall  # 1  _PyEval_EvalFrameDefault  # 2  _PyEval_Vector  # 3  PyObject_Vectorcall  # 4  <unknown>[Manual frame pointers]Total frames: 4Showing first 4 frames:  # 0  0x57385e3d3303  # 1  0x(nil)  # 2  0x57385e8bc7e0  # 3  0x(nil)

Notice the missing frames!

However, I have made a very interesting discovery --- compiling the interpreter with a recent enough clang version (tested with clang-20/21) to the JIT restores the frames!!!

[GNU backtrace]Total frames: 29Showing first 10 frames:  # 0  /home/ken/Documents/GitHub/cpython-unwind/stackunwind.cpython-315-x86_64-linux-gnu.so(+0x280a) [0x797cf3f7c80a]  # 1  ../cpython/python(PyObject_Vectorcall+0x43) [0x64be6334e693]  # 2  ../cpython/python(_PyEval_EvalFrameDefault+0x5d3e) [0x64be6347f63e]  # 3  ../cpython/python(+0x217706) [0x64be63479706]  # 4  ../cpython/python(PyObject_Vectorcall+0x43) [0x64be6334e693]  # 5  ../cpython/python(_PyEval_EvalFrameDefault+0x3768) [0x64be6347d068]  # 6  ../cpython/python(+0x217706) [0x64be63479706]  # 7  ../cpython/python(PyObject_Vectorcall+0x43) [0x64be6334e693]  # 8  ../cpython/python(_PyEval_EvalFrameDefault+0x3768) [0x64be6347d068]  # 9  ../cpython/python(+0x217706) [0x64be63479706]  ... (19 more frames)[libunwind]Total frames: 28Showing first 10 frames:  # 0  PyObject_Vectorcall+0x43  # 1  _PyEval_EvalFrameDefault+0x5d3e  # 2  _PyEval_Vector+0x266  # 3  PyObject_Vectorcall+0x43  # 4  _PyEval_EvalFrameDefault+0x3768  # 5  _PyEval_Vector+0x266  # 6  PyObject_Vectorcall+0x43  # 7  _PyEval_EvalFrameDefault+0x3768  # 8  _PyEval_Vector+0x266  # 9  PyObject_Vectorcall+0x43  ... (18 more frames)[libdw (DWARF)]Total frames: 28Showing first 10 frames:  # 0  PyObject_Vectorcall  # 1  _PyEval_EvalFrameDefault  # 2  _PyEval_Vector  # 3  PyObject_Vectorcall  # 4  _PyEval_EvalFrameDefault  # 5  _PyEval_Vector  # 6  PyObject_Vectorcall  # 7  _PyEval_EvalFrameDefault  # 8  _PyEval_Vector  # 9  PyObject_Vectorcall  ... (18 more frames)[Manual frame pointers]Total frames: 16Showing first 10 frames:  # 0  0x64be6334e693  # 1  0x2  # 2  0x64be63479706  # 3  0x2  # 4  0x64be63479706  # 5  0x2  # 6  0x64be63479706  # 7  0x(nil)  # 8  0x64be63479706  # 9  0x(nil)  ... (6 more frames)

So the solution to the stack unwinding seems to be to mandate compiilng CPython with the same clang as the JIT!