This commit introduces support for running clang-repl and executing C++
code interactively inside a Javascript engine using WebAssembly when
built with Emscripten. This is achieved by producing WASM "shared
libraries" that can be loaded by the Emscripten runtime using dlopen()
Details
- Reviewers
v.g.vassilev sgraenitz lhames pmatos tlively
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This cannot built yet because it depends on lld which does not seem to usable from clang directly. I am looking for feedback/ideas on how to proceed.
This is quite exciting! Most of it looks already good enough to me. See inline comment.
clang/lib/Interpreter/WASM.cpp | ||
---|---|---|
79 | I am not sure how we can solve that dependency here. Worst case scenario, could we check if lld is installed and make a system call? |
clang/lib/Interpreter/WASM.cpp | ||
---|---|---|
79 | AFAIK we can't really exec() within Emscripten. |
Here's a demo of it in action with clang and lld linked statically out of tree. https://wasmdemo.argentite.me
Very nice idea!
clang/lib/Interpreter/CMakeLists.txt | ||
---|---|---|
21 | Elsewhere in LLVM either use WebAssembly (spelled out). If you really prefer to keep it short you should use Wasm (not all caps). Also, I wonder if we should call this Emscripten given that it seems emscripten specific.. then you could have another one called WASI or WebAssembly for the less specific one? | |
clang/lib/Interpreter/WASM.cpp | ||
79 | This looks its using the in-process call to the linker library, rather then an exec of the linker process.. which could work. But is it OK to have the compiler depend on the linker like this? |
I suppose you could build a similar thing that runs under node and uses that wasi-unknown-unknown target?
clang/lib/Interpreter/WASM.cpp | ||
---|---|---|
79 | Well, this is what we would like to avoid. Somehow. Initially, I thought we could move the relevant lld bits in the ORC infrastructure but maybe that’s not a good idea after all. Is there a suitable place where we could move that lld logic in LLVM? |
ood idea after all. Is there a suitable place where we could mo
clang/lib/Interpreter/WASM.cpp | ||
---|---|---|
79 | Perhaps you could wrap all of this in if __EMSCRIPTEN__ or even something like if STATICALLY_LINKED_LLD so it would only be available in your special build of the compiler? |
clang/lib/Interpreter/WASM.cpp | ||
---|---|---|
79 | @argentite could we try @sbc100's proposal? |
Yes, I think that's the simplest solution. __EMSCRIPTEN__ probably won't work because somebody may want to build for Emscripten without lld. STATICALLY_LINKED_LLD would probably be better. But I could not figure out how to do that in the build system.
Elsewhere in LLVM either use WebAssembly (spelled out). If you really prefer to keep it short you should use Wasm (not all caps).
Also, I wonder if we should call this Emscripten given that it seems emscripten specific.. then you could have another one called WASI or WebAssembly for the less specific one?