Windows: Unhandled exceptions from C++ backend cause jank crash

[ikappaki]

Issue Description

(Refilling of ikappaki#2, to track llvm compiler missing exception support on Windows, as discussed in #716)

Jank on Windows throws an error or crashes when an exception is raised from the C++ backend.

Reproduction Steps

To reproduce, run the Jank REPL and define a lambda that throws an exception:

user=> ((fn* [] (throw false)))
libunwind:      pc not in table, pc=0x20E12B700DD
Uncaught exception: false

The specified module could not be found.

jank health check

─ system ───────────────────────────────────────────────────────────────────────────────────────────
─ ✅ operating system: windows
─ ✅ default triple: x86_64-w64-windows-gnu

─ jank install ─────────────────────────────────────────────────────────────────────────────────────
─ ✅ jank version: jank-0.1-582c09bfd75c25e90f4d9584a5c7003a35320f0a
─ ✅ jank assertions are enabled; performance will be impacted
─ ✅ jank resource dir: ../lib/jank/0.1  (not found)
─ ✅ jank resolved resource dir: 0x170b61c6670  (ignored for dev build)
─ ✅ jank user cache dir: D:\removeme\msys64\jank5\home\chaos/.cache/jank/x86_64-w64-windows-gnu-d41e18d22073dff61785592e037f567ed6512e5c4e895943d6168cbfe3339d2e  (not found)

Stack trace

#0  in _gxx_personality_seh0 at libc++.dll
#1  in GCC_specific_handler at libc++.dll
#2  in _gxx_personality_seh0 at libc++.dll
#3  in _chkstk at ntdll.dll
#4  in RtlLocateExtendedFeature at ntdll.dll
#5  in RtlRaiseException at ntdll.dll
#6  in RaiseException at KERNELBASE.dll
#7  in Unwind_RaiseException at libc++.dll
#8  in _cxa_throw at libc++.dll
#9  in jank_throw at c_api.cpp:938
#10
#11
#12
#13
#14 in jank::read::lex::big_decimal>>::__assignment at variant:901
#15
#16
#17
#18
#19 in std::__1::__variant_detail::__union< at construct_at.h:38
#20
#21
#22 in jank::read::lex::big_decimal>::__impl[abi:ne210107] at variant:1037
#23 in jank::runtime::visit_object<jank::runtime::dynamic_call at visit.hpp:182
#24 in jank::runtime::dynamic_call at callable.cpp:25
#25 in _ZZN4jank8evaluate4evalEN3jtl3refINS_7analyze4expr4callEEEENK3$_0clINS_7runtime4orefINS9_3obj12jit_functionEEEEENSA_INS9_6objectEEET_ at evaluate.cpp:334
#26 in jank::runtime::visit_object<jank::evaluate::eval at visit.hpp:182
#27 in jank::evaluate::eval at evaluate.cpp:318
#28 in _ZZN4jank8evaluate4evalEN3jtl3refINS_7analyze10expressionEEEENK3$_0clINS2_INS3_4expr4callEEEEEDaT_ at evaluate.cpp:272
#29 in jank::analyze::visit_expr<jank::evaluate::eval at visit.hpp:53
#30 in jank::evaluate::eval at evaluate.cpp:272
#31 in jank::runtime::context::eval_string at context.cpp:177
#32 in jank::runtime::context::eval_file at context.cpp:160
#33 in jank::repl at main.cpp:200
#34 in main::$_0::operator at main.cpp:329
#35 in main::$_0::__invoke at main.cpp:287
#36 in jank_init_with_pch at c_api.cpp:1039
#37 in jank_init at c_api.cpp:1000
#38 in main at main.cpp:287
#39 in __tmainCRTStartup at crtexe.c:236
#40 in mainCRTStartup at crtexe.c:122
#41 in BaseThreadInitThunk at KERNEL32.DLL
#42 in RtlUserThreadStart at ntdll.dll

OS Version Information

MS-Windows 11

I acknowledge that:

• I have searched the jank repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[ikappaki]

LLVM issue reported at llvm/llvm-project#126365

The issue also affects the test suite, which crashes on tests that throw exceptions:

$ build/jank-test.exe
[doctest] doctest version is "2.4.12"
[doctest] run with "--help" for options
testing file test/jank/call/fail-incorrect-arity.jank => success
testing file test/jank/call/fail-nil.jank => success
testing file test/jank/call/pass-empty.jank => success
testing file test/jank/call/pass-literal.jank => success
testing file test/jank/call/pass-var-within-var.jank => success
testing file test/jank/cpp/auto-box/pass-argument.jank => success
testing file test/jank/cpp/auto-box/pass-closure.jank => success
...
testing file test/jank/cpp/closure/pass-convertible.jank => success
testing file test/jank/cpp/constructor/builtin/fail-extra-arguments.jank => success
testing file test/jank/cpp/constructor/builtin/fail-incompatible-arguments.jank =>
$ 

As a workaround, the failing test is excluded using compiler+runtime/test/jit_windows_skips.txt, which lists the tests to skip when running the suite on Windows.

[ikappaki]

This issue also affects some bash tests, and those have been disabled as such in their corresponding test files:

• compiler+runtime/test/bash/clojure.test/src/clojure_test/self_test.jank
• compiler+runtime/test/bash/error-reporting/bin/jank/test/error_reporting.clj
• compiler+runtime/test/bash/cli/pass-test

[ikappaki]

This issue also affects some clojure-test-suite tests, and those have been disabled as such in the jank clojure test suite runner:

• test/bash/clojure-test-suite/src/jank_test/run_clojure_test_suite.cljc

[ikappaki]

An LLVM support issue has been opened to track support for Windows SEH without the ORC runtime: llvm/llvm-project#163503. The issue includes an initial sketch for how the SEH plugin could look in LLVM 23

While testing the plugin against the full jank test suite, I ran into missing support pieces and opened follow up fixes in lhames/llvm-project#5 on top of the original sketch branch, pending review and guidance.

The changes have also been backported to the Jank LLVM 22 snapshot in jank-lang/llvm-project#3. When jank is built against this version, the full test suite now passes, including the exception related tests that were previously failing without these fixes.

While waiting for Lang to provide guidance on how these changes should be incorporated into LLVM 23 or potentially backported to the official LLVM 22 branch, there are a couple of short term options we could consider:

1. Merge the changes into the jank LLVM 22 snapshot branch and advance the commit hash in build-clang so they are picked up automatically when building clang. The changes are isolated to JITLink COFF support (Windows only), so they should not affect the other platforms.
2. Create a patch containing the fixes and apply it from the MINGW-packages/mingw64-llvm package when build-clang performs a windows LLVM build. This would avoid modifying the snapshot branch directly.

Hi @jeaye, do you have a preference for how these fixes should be applied to the jank LLVM 22 snapshot while we wait for the upstream LLVM direction?

[jeaye]

Great job getting this going!

Firstly, we don't want a PR into Lang's repo. That's not going to help us get upstream. Instead, we want a PR into the LLVM repo. Then leave a comment to ping Lang (not in the description) for review.

Let's hold off on merging this into jank's fork until we get everything merged upstream. Once it's merged upstream, I will update jank's fork to point at the new commit and we will build from there.

The important distinction is that I don't want jank's LLVM fork to be diverged from upstream LLVM at all. We can use non-released LLVM commits, if it gets us what we need, but those commits need to be merged into LLVM main.

[ikappaki]

HI @jeaye, I've opened a PR in Lang's repo since for first time guidance on what to do next, since the fixes are on top of his branch in the same repo and also giving him a chance to have a quick look at the changes. He replied a few days ago saying he'd take a look, but let me know if you think it would be better to go ahead and open a PR against the main LLVM branch even if we don't hear back.

Understood about holding off into jank's fork.

In the meantime, I've repurposed my https://github.com/ikappaki/jank-win fork to carry the SEH support compiler changes and enable all the exceptions tests, and the https://github.com/ikappaki/jank-win-release repo to produce prebuilt binaries. That at least provides a way to publish the fixes indirectly while we wait for upstream review and merge.

Thanks

[jeaye]

Thanks for the update! Let's hold off and give Lang some time. I will be meeting up with him in a few weeks and will bring this up if there hasn't been any progress.