subagent transcript

I need to investigate emscripten's JSPI support and how it handles suspension across different exception handling mechanisms. My plan is to check the JSPI configuration in emscripten 4.0.12, test whether the invoke_* suspension works correctly with JavaScript exception handling, and then verify the same behavior with WebAssembly exception handling under clang-22, particularly with nested try/catch patterns like those in OCCT.

JSPI is available, so I'll look into the configuration details and check what Node flags are needed for it.

Node 22.16 has V8 12.4 where JSPI appears to be stabilized without needing experimental flags, so I'm going to run some decisive tests starting with a basic JSPI check, then move on to the invoke_* test and wasm exception handling with optimized compilation.

Setting up the test directories now.

V8 14.6 is recent enough that JSPI should be stable without needing any flags, so I can write a straightforward JSPI test now.

I need to find the right Node.js flag for JSPI support, checking whether the environment has `WebAssembly.Suspender` or `WebAssembly.Function` with suspending capabilities.

So the `--experimental-wasm-type-reflection` flag actually enabled JSPI support, even though `--experimental-wasm-jspi` itself isn't recognized as a direct Node option. It seems JSPI might be stable in V8 14.6 by default, but emscripten's tests specifically check for type reflection support to verify it's working.

Now I'm setting up the real test: can JSPI suspend through the invoke_ trampolines that emscripten uses for exception handling? When `-fexceptions` is enabled, calls that might throw get wrapped in JS try/catch frames via `invoke_vii` and similar functions. Historically JSPI couldn't suspend across JS frames at all, so this will be the critical test — building a program that suspe  …

I'm seeing that the WebAssembly.Suspending constructor error only appears with the type-reflection flag, while the actual JSPI stack-switching API requires a different flag. The basic test worked earlier and printed the expected output using EM_ASYNC_JS with the same instrumentWasmImports approach, so I'm trying to figure out why that succeeded but this one's failing.

The key difference might be the optimization level — the basic build used -O0 while the invoke test used -O1, though both should theoretically use Suspending. I'm wondering if Node.js needs the `--experimental-wasm-jspi` flag or if there's a specific V8 flag I'm missing. Since V8 14.6 has JSPI as stable, it should be available  …

JSPI appears to be stable in V8 14.6 since the experimental flag is gone, which should make WebAssembly.Suspending available by default. But it's not showing up unless type-reflection is enabled — the basic test worked with that flag, so I need to rerun it and compare to see what's actually different between the two setups. understand what the detection logic is doing in the generated code.

So `WebAssembly.Suspending` exists as a function, but it's not actually a constructor—it doesn't have the [[Construct]] internal slot. The error makes sense now; emscripten's runtime might be polyfilling or checking for this differently. I should test whether calling `new` on it directly works or if there's something else going on with how the module is handling it.

The `new WebAssembly.Suspending` call works at the top level, but it's failing inside the invoke test module—that's puzzling. I'm wondering if emscripten's generated code is doing some feature detection on `WebAssembly.Suspending` earlier, or maybe the minified runtime in the -O1 build is renaming the `WebAssembly` variable somehow. Let me check what's actually happening at line 966 in the generated invoke t.js file.

I'm realizing the critical mechanism here: when JSPI and `-fexceptions` are both enabled, emscripten's `Asyncify.instrumentWasmImports` automatically wraps every invoke_ trampoline function as a suspending import using `WebAssembly.Suspending`, which is what allows the async/await pattern to work across the wasm boundary.

But there's a puzzling contradiction — the error says `WebAssembly.Suspending is not a constructor`, yet I can verify it IS a constructor at the top level. The issue might be that inside the module context, something's different — maybe a stale compiled artifact, or the `WebAssembly` object itself is shadowed somehow. Let me re-run the test fresh to see what's actually hap  …

I'm noticing the Node version shifted from v22.16.0 to v26.2.0 — looks like the system is picking up a different Node installation now instead of the emsdk one. I should explicitly use the emsdk node to keep things consistent.

The real issue though: I accidentally compiled with the `-c` flag which created an object file and overwrote the linked WebAssembly binary, causing the LinkError. I need to rebuild without that flag and stick with the emsdk node at `/opt/toolchains/emsdk/node/22.16.0_64bit/bin/node` since that's what the task specifies for testing.

I'm noticing a discrepancy with the emsdk node version and WebAssembly.Suspending support. The basic test seemed to work, but I need to clarify which node version actually ran it and whether emsdk node 22.16 is the issue here.

Let me directly test whether WebAssembly.Suspending works as a constructor on emsdk node 22.16 to resolve this contradiction.

On older Node versions like 22.16 with V8 ~12.x, I need the `--experimental-wasm-jspi` and `--experimental-wasm-stack-switching` flags to get WebAssembly.Suspending working, whereas type-reflection alone isn't enough. The earlier test that seemed to work with just type-reflection must have been running on a different Node version where JSPI was already enabled by default.

Let me test the invoke case with the correct flags on emsdk node 22.16, and also run tests on the newer system node v26.2.0 which has stable JSPI support — that'll better match what Chrome 137+ offers.

So the issue is that emsdk's bundled Node 22.16 has an older V8 version that still uses the `WebAssembly.Suspender`/`promising` API, but emscripten 4.0.12 expects the newer `WebAssembly.Suspending` constructor syntax—they're incompatible, which is why the JSPI support isn't working even with the experimental flag enabled.

System Node v26.2.0 with V8 14.6 has stable JSPI support where `WebAssembly.Suspending` works out of the box, and that aligns with Chrome 137+ which is the actual target. Now I need to run the full invoke test on Node 26.2.0 to see if JSPI works correctly with exceptions and suspend calls across try/catch boundaries.

So the core issue is that even with emscripten 4.0.12 wrapping the `invoke_ii` function in `WebAssembly.Suspending`, V8 still throws a `SuspendError` when the suspension actually crosses a JS frame boundary at that point. The wrapping didn't solve the problem because the suspension is happening within the JS frame itself rather than at a safe boundary. allows suspending across a JS frame that isn't itself a Suspending boundary returning a promise. So the result is a SuspendError.

This confirms the R10 blocker is still present in emscripten 4.0.12 with node V8 14.6 — JSPI can't suspend through the JS-EH invoke_* trampolines. The Suspending wrapper doesn't solve it because the suspension orig  …

The issue is that emsdk's node 22 is being prepended to PATH after sourcing env.sh, which is causing the WebAssembly.Suspending constructor error. I need to use the system node explicitly by finding its full path or using /usr/bin/node directly to avoid this conflict.

I've confirmed the key distinction: when suspension happens outside of a try/catch landing pad, everything works fine and returns the expected result, but when suspension occurs within a callee that's invoked through an exception handling trampoline, it fails with a suspension error. This confirms that the R10 blocker is a genuine issue.

The real problem for FreeCAD is that JSPI can't suspend across emscripten's invoke_* frames, which are everywhere in a -fexceptions build—they wrap any code inside try blocks or with C++ destructors. Since Qt's event loop relies on suspension and OCCT/Qt code is full of exception handling, this combination is fundamentally broken. The only viable path forwa  …

I need to figure out how OCCT was compiled and whether it used the right exception handling flags. The core issue is testing whether I can compile WebAssembly code with wasm-EH that works with OCCT's patterns, and whether V8 will accept it. Ideally I'd recompile OCCT with -fwasm-exceptions to properly test the mismatch, but that's a massive undertaking since the libraries were prebuilt with JavaScript exception handling to match FreeCAD.

The real claim I'm investigating is that LLVM is generating invalid br_table instructions in OCCT's try/catch patterns when using -fwasm-exceptions, which V8 then rejects. Let me try reproducing this with clang-22 by writing representative C++ code with nes  …

I'm shifting my approach to look for WebAssembly exception handling opcodes directly—either `try_table` from the newer exception handling spec or `invoke_` imports that indicate exception support. Let me scan through libTKernel to see what exception mechanisms are actually being used.

Actually, the most direct way is to just write a test case that reproduces the miscompilation using OCCT's own exception handling patterns, specifically their Standard_ErrorHandler macros and try-catch blocks.

Now I'm setting up a comprehensive test for wasm exception handling codegen—I'll create C++ code that reproduces the nested try/catch pattern with rethrow and catch_all_ref that generates br_table, then compile it with -fwasm-exceptions and verify it runs correctly in V8 through Node 26. I'm also planning to compile an actual OCCT header-using translation unit to make sure the test is realistic.

Writing test code...

The wasm-EH test with complex nested exception handling is working correctly across all test cases on node26—destructors run properly when no exception is thrown, runtime errors get caught and rethrown through multiple levels, integer throws are handled by catch-all blocks, and logic errors follow the expected catch path.

Now I need to test with actual OCCT code to reproduce the specific br_table miscompilation that was flagged. Since node22 doesn't support wasm-EH, I'll need to use node26 or Chrome137+. The challenge is that prebuilt OCCT libraries with JS-EH don't link easily, but I can compile a real OCCT source file with -fwasm-exceptions and validate the generated module with binaryen   …

I'm going to compile several representative OCCT source files with the `-fwasm-exceptions` flag to object files, then use LLVM tools to disassemble and validate them—this should expose the invalid `br_table` instruction that manifests during validation.

Actually, the cleanest approach is to compile a real OCCT source file with `em++ -fwasm-exceptions -c` to an object, then disassemble it with `llvm-objdump` to look for the problematic `br_table` inside the exception handling pad. To truly verify the bug, I need a runnable module that V8 will reject during instantiation, so I should compile a real OCCT source file with its minimal dependencies into a standalone module with stubs. But that's   …

I've pinpointed the exact reproducer: the miscompile happens with OCCT libraries (TKFillet, TKGeomAlgo, TKShHealing, TKTopAlgo) and manifests as "br_table: label arity inconsistent" in V8 or "popping from empty stack" in Binaryen. The issue stems from `try_table`/`catch_all_ref` with rethrow having inconsistent label arity, and `-Os` doesn't sidestep it. R10 already tested JS-EH plus JSPI and found the same underlying problem.

Now I need to verify whether this wasm-EH miscompile still exists with clang-22 (LLVM 22), since R10's testing was done at an earlier LLVM version. The approach is to compile the actual offending OCCT source files from those toolkits with `-fwasm-exceptions` using cla  …

Looking at the pattern, it seems the bare rethrows are mostly coming from compiler-generated cleanup code during exception unwinding rather than explicit throw statements. The real trigger appears to be OCC_CATCH_SIGNALS style try blocks where objects need cleanup. Instead of trying to trace each case individually, I should just compile a broader set of examples to see the pattern more clearly.

I'll compile OCCT sources from the problematic toolkits using -fwasm-exceptions and run wasm-opt on them to catch the "popping from empty stack" error directly. This will let me test the miscompile with clang-22 in a more systematic way. I need to set up the include paths properly—the flattened heade  …

The object compiles, so now I need to validate it and check for the miscompile. The binaryen error about popping from an empty stack occurs when wasm-opt processes it, so let me try running wasm-opt directly on the object file—though I'm not sure if it can handle relocatable objects without the `-g` flag. The real test would be to either compile the source to a standalone module or link it into an executable, but that depends on resolving dependencies first.

I'm seeing that the relocatable object has multiple exception handling references that wasm-opt can't fully validate since it's not a standard module yet. The real test would be building a small executable with the actual OCCT codegen from those toolkits, linking it against the OCCT libraries, and validating through V8—but since the OCCT libs were compiled with JS-EH, I'd need to compile those specific source files myself with the right flags to avoid a mismatch.

A better approach: link the compiled objects into a proper wasm module using wasm-ld with undefined symbols allowed and no entry point, which produces a real (non-relocatable) module I can validate with V8. The validation happens a  …

The issue is that zsh doesn't automatically word-split unquoted variables like bash does, so I need to switch to bash or use an array instead to properly iterate over the file list.

Now I'm linking all seven compiled modules into a single non-relocatable WebAssembly module with undefined symbols allowed, then validating it against V8 in Node 26 to confirm the exception handling implementation is correct with clang-22.

The linker is stripping out all the code because nothing's being exported or referenced. I need to preserve the OCCT functions by either exporting all symbols or disabling garbage collection during linking, so I'll relink with flags to keep everything and make it visible.

I'm seeing a critical issue with the emscripten configuration: `--export-all` combined with `--no-gc-sections` forces all undefined symbols to resolve, which means vtables and typeinfo must be available, so `--allow-undefined` won't work in this setup. More importantly, the linker is using both legacy and modern exception handling flags simultaneously—`-mllvm -wasm-use-legacy-eh` alongside `-mllvm -wasm-enable-eh` and `-lc++-legacyexcept`—which suggests emscripten 4.0.12 is defaulting to legacy wasm exception handling.

The real puzzle is whether the compiled object files actually use the legacy exnref opcodes or the newer try_table/catch_all_ref standard, and whether either produces a valid  …

The object is using the legacy WebAssembly exception handling opcodes rather than the newer try_table approach, which means emcc 4.0.12 defaults to the legacy EH proposal—though Binaryen has trouble parsing it and V8's validity is uncertain. The br_table instructions are just standard switch statements.

Now I need to test whether V8 in Node 26 can actually accept a real module with these legacy-EH functions. I'm thinking about how to link everything together: my seven object files plus the OCCT libraries, with a minimal main that references enough symbols to keep the functions from being garbage collected. The challenge is that without --export-all, the linker's gc-sections will strip unref  …

The prebuilt OCCT libraries were compiled with JavaScript exception handling enabled, but my linker is using the legacy WebAssembly exception runtime, which doesn't include the `__resumeException` symbol that the prebuilt libs expect—this is a fundamental mismatch in exception handling implementations.

Rather than rebuild OCCT entirely with WebAssembly exceptions (which would be massive), I can validate the code section structurally by creating a side module from my compiled objects. This would let V8 validate the exception handling opcodes and control flow without needing all the external symbols to resolve, giving me a definitive answer about whether the codegen is actually valid.

The dead code elimination is stripping everything because side modules only keep exported symbols by default. I need to preserve all functions, so I'll try using `-sLINKABLE=1` to export everything and disable dead code elimination. Though this might bring back the vtable and typeinfo undefined issues, so I may need to adjust the approach.

I'm wondering if the issue is that these are LTO bitcode objects, which might be getting treated differently during the link step—the optimizer could be dropping unreferenced functions even though they have external linkage, unless LINKABLE is explicitly set to preserve them.

Let me verify what's actually happening: earlier llvm-objdump showed wasm opcodes, so these are definitely wasm objects, not bitcode. That means the DCE at link time is removing them because nothing references them and they're not exported. For a side module, I should try combining --no-gc-sections with --export-all to force keeping all symbols, though I'm puzzled why LINKABLE didn't already achieve this since it's sup  …

The issue is that the side module's weak symbols are being stripped by the linker's dead code elimination. I need to disable garbage collection for the side module with `--no-gc-sections` and use `--export-all` to ensure the OCCT class methods are properly exported instead of being discarded.

I need to recompile those 7 object files with the -fPIC flag alongside -fwasm-exceptions to make them compatible with the side module approach. The -fPIC flag shouldn't significantly alter the exception handling codegen, though there's a nagging concern that it might change the generated code enough that it won't accurately represent how the actual static FreeCAD build behaves.

I've got a substantial 890KB module with 734 functions using OCCT's legacy WebAssembly exception handling codegen, so now I need to validate it against V8 in Node 26 to see if it actually works. I'll run WebAssembly.validate to check the module structure, then attempt instantiation and compilation to trigger full function-body validation. Since the module uses legacy EH opcodes, I need to verify whether V8 14.6 has the legacy EH proposal enabled by default or if it requires a flag.

The OCCT WebAssembly module with exception handling is validating and compiling successfully in V8 14.6, which means the 734 functions from the real OCCT geometry libraries are working properly with the legacy exception handling opcodes.

The key insight is that emcc 4.0.12 now defaults to legacy wasm-EH rather than the new try_table approach that R10 flagged as problematic, and the legacy path is validating cleanly in V8 even though R10 said Binaryen couldn't parse it. I've tested 7 files across three of the four flagged toolkits so far, but I should also check TKGeomAlgo and TKTopAlgo, plus test whether the new try_table path specifically still breaks as R10 reported. There's also the ques  …

Binaryen successfully processes the legacy exception handling version of the OCCT module with the `-legacy` flags, which tells it to handle the older EH opcodes. Now I'm switching to test the new exception handling model using try_table by setting `WASM_LEGACY_EXCEPTIONS=0` — this is where the R10 failure occurs. I need to recompile with this setting and then validate it through both the validator and Binaryen to see where the issue emerges.

I'm working with the new exception handling standard that uses try_table, catch_all_ref, and throw_ref—this matches the R10 invalid br_table case. I should create a test module and verify it works correctly with V8 and binaryen.

The new try_table path is showing really interesting results—V8 accepts it and compiles the module successfully with nearly a thousand exports, which means the clang-22 exception handling codegen isn't being rejected like it was before. But Binaryen's hitting a wall with a block type error that requires additional features for the exnref result type in the try_table construct.

The issue is that I didn't pass the right feature flags to Binaryen—it needs the correct exception handling flag to understand the new exnref model, not just the legacy try/catch support. What's crucial here is that my emscripten build with WASM_LEGACY_EXCEPTIONS=0 and -O2 actually succeeded at the link stage, which m  …

Running binaryen with all features enabled shows that version 123 handles the new try_table and exnref exception handling cleanly, which means the earlier compilation failure was due to incorrect feature flags rather than a real incompatibility. So for this dimension, the R10 miscompile issue doesn't actually reproduce with the current toolchain setup.

Both the legacy and new exception handling approaches compile real OCCT source files successfully, validate as proper WebAssembly modules, and pass through V8 and binaryen optimization without issues—confirming that the LLVM codegen bug blocking wasm-EH has been fixed. This opens up the possibility of using wasm-EH with JSPI, since native was  …

I'm seeing the key breakthrough: when using JSPI with wasm exceptions and the `-fwasm-exceptions -sJSPI` flags, the suspend point lands inside a try/catch block with a Guard destructor—the exact scenario that previously failed under JS-EH with that "SuspendError" about trying to suspend JS frames. But with wasm-EH, those problematic invoke trampolines disappear entirely, which resolves the issue.

The test output confirms it works: the suspension cleanly crosses the try/catch frame, resumes correctly, the destructor runs, and there's no trap. So the solution is JSPI paired with native wasm exceptions, which eliminates both blockers from the earlier documentation—the OCCT miscompile is fixed,  …