This is an archive of the discontinued LLVM Phabricator instance.

WIP: [clang-repl] Basic WebAssembly support for running inside a JS engine
Needs ReviewPublic

Authored by argentite on Aug 16 2023, 9:43 PM.



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()

Diff Detail

Event Timeline

argentite created this revision.Aug 16 2023, 9:43 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 16 2023, 9:43 PM
argentite requested review of this revision.Aug 16 2023, 9:43 PM

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.


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?

argentite added inline comments.Aug 23 2023, 4:48 AM

AFAIK we can't really exec() within Emscripten.

Let's add more reviewers to see if we can figure out how to move forward here.

Here's a demo of it in action with clang and lld linked statically out of tree.

Very nice idea!


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?


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?

v.g.vassilev added inline comments.Aug 23 2023, 8:50 AM

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


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?

v.g.vassilev added inline comments.Aug 24 2023, 7:20 AM

@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.