WASM build fails to link C setjmp/longjmp with undefined __wasm_setjmp symbols

[thomak-dev]

Description

A minimal Microsoft.NET.Sdk.WebAssembly project fails to link when a native C file referenced with NativeFileReference uses <setjmp.h> / setjmp / longjmp.

The project explicitly passes Emscripten's wasm longjmp mode:

<EmccFlags>-sSUPPORT_LONGJMP=wasm</EmccFlags>

A standalone compile with the bundled Emscripten toolchain succeeds for the same C file using -fwasm-exceptions -sSUPPORT_LONGJMP=wasm, but the .NET WebAssembly SDK build fails with unresolved __wasm_setjmp symbols.

Reproduction Steps

Either download JumpTest.zip or:

1. Create a new WASM browser project:

dotnet new wasmbrowser -n JumpTest
cd JumpTest

2. Add this to the project file:

<EmccFlags>-sSUPPORT_LONGJMP=wasm</EmccFlags>

and reference the native C file:

<NativeFileReference Include="jump_test.c" />

3. Add jump_test.c:

#include <setjmp.h>

int setjmp_roundtrip(void)
{
    jmp_buf buffer;
    int result = setjmp(buffer);

    if (result == 0)
        longjmp(buffer, 42);

    return result;
}

4. Call it from Program.cs:

using System;
using System.Runtime.InteropServices;

Console.WriteLine($"setjmp_roundtrip() = {NativeMethods.SetjmpRoundtrip()}");

internal static partial class NativeMethods
{
    [LibraryImport("__Internal", EntryPoint = "setjmp_roundtrip")]
    internal static partial int SetjmpRoundtrip();
}

5. Build:

dotnet build

Expected behavior

The project should compile and link successfully, or the SDK should document/report that native setjmp/longjmp is unsupported for this target.

Since the project passes -sSUPPORT_LONGJMP=wasm, Emscripten's wasm SjLj support should be included during linking.

Actual behavior

The build fails during the native link step:

undefined symbol: __wasm_setjmp
undefined symbol: __wasm_setjmp_test

The failure occurs even with:

<EmccFlags>-sSUPPORT_LONGJMP=wasm</EmccFlags>

Allowing undefined symbols lets the build finish, but the produced wasm still imports env.__wasm_setjmp and env.__wasm_setjmp_test, so that is not a valid workaround.

Regression?

Unknown

Known Workarounds

Unknown

Configuration

.NET configuration:

.NET SDK:
 Version:           10.0.301
 Commit:            96856fd726
 Workload version:  10.0.301.1
 MSBuild version:   18.6.4+96856fd72

Host:
 Version:      10.0.9
 Architecture: x64
 Commit:       901ca94124

Installed workloads:
 wasm-tools        10.0.109/10.0.100
 wasm-experimental 10.0.109/10.0.100

Which version of .NET is the code running on?

TargetFramework: net10.0
Microsoft.NETCore.App: 10.0.9
SDK: 10.0.301

OS and version:

Windows 10.0.26200
RID: win-x64

Other information

No response

[thomak-dev]

To add a bit more context: This is not just "I can't use setjmp in C". The problem manifested for me when trying to link a C library (FreeType)

Can someone at least acknowledge this bug?

[pavelsavara]

@thomak-dev try adding

 <ItemGroup>
      <EmccExportedRuntimeMethod Include="__wasm_setjmp" />
      <EmccExportedRuntimeMethod Include="__wasm_setjmp_test" />
 </ItemGroup>

I'm no sure about number of underscores here.

Also make sure that you compile your C library with emscripten version 3.1.56

Use binlog for build troubleshooting, -sVERBOSE=1 for emcc and $env:EMCC_DEBUG=2 will give you much more details.

[thomak-dev]

@pavelsavara Thanks, I tried adding the suggested XML with varying amounts of underscores but the build still fails.

The binlog confirms that the values reach emcc, but the symbols remain undefined. Aren't Emscripten's EXPORTED_RUNTIME_METHODS just for exposing them to Javascript anyway? (I might be wrong on the latter)

I'm using the bundled Emscripten toolchain, and confirmed it is v3.1.56.

It looks like the bundled Clang is emitting the newer SjLj ABI (__wasm_setjmp/__wasm_setjmp_test) while the Emscripten v3.1.56 runtime source define the older saveSetjmp/testSetjmp ABI. Emscripten v3.1.57 defines the new, matching ABI.

I assume the fix is to regenerate the .NET-cached Emscripten from v3.1.57 so that it contains a libcompiler_rt-wasm-sjlj.a that contains the new ABI.

I've attached the binlog and verbose logs. I zipped the binlog, because GitHub prevented me from directly uploading it.

verbose.log
log.zip

[pavelsavara]

@thomak-dev your log correctly is showing dotnet fork of LLVM

https://github.com/dotnet/llvm-project/tree/dotnet/main-19.x which is LLVM 19.1.0 final + 234 dotnet patches.
The upstream emscripten 3.1.56 → LLVM 34ba907 = 19.0.0-git (pre-release dev snapshot)

So, the solution could be to use our bundled LLVM/emscripten to build also your native lib.