Sam Clegg

Given this should have basically zero performance overhead for wasm-to-wasm indirect calls I think it seems like a reasonable change. Making this change would eliminate the horrible hack that emscripten...

Yes, I was imagining as your describe: A table slot containing a polymorphic JS function that would never result in a run-time type check failure when called indirectly. Its useful...

> > Without this the (lazy loading) dynamic linker needs to know not just names but also function signatures. > > That's true, but given the js-types proposal, can't the...

Sadly this doesn't work since table slots today are `anyfunc`, so the slot itself doesn't have type. Its type is not checked/known until its used in a call_indirect instruction. Also,...

Even if we had a different table to every possible signature, the problem would then be more like: given a JS function which table should I try to put it...

For fchmod/chmod the underlying functions were added to WASI ephemeral here: https://github.com/WebAssembly/WASI/pull/170/files. I imagine that once we make next snapshot and this migrates into wasi-sdk we can them implement fchmod...

The wask-sdk does not support setjmp or other non-local control flow concepts (such as C++ exceptions) yet because WebAssembly does not yet support such things. There are several proposals in...

Apologies, on re-reading this does look like something that could probably be fixed. Most likely the correct solution is to patch libc++ headers to avoid including `c++/v1/setjmp.h`. We should also...

Instructions for building from source are in the README: https://github.com/WebAssembly/wasi-sdk I don't know of anyone working on a linux arm64 build. We build our images using github CI I guess...

libclang_rt.builtins-wasm32.a built a build of llvm's compiler-rt. You can see how we build it as part of wasi-sdk here: https://github.com/WebAssembly/wasi-sdk/blob/1a953299860bbcc198ad8c12a21d1b2e2f738355/Makefile#L98-L124