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

Vassil Vassilev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Aug 24 07:20:47 PDT 2023


v.g.vassilev added inline comments.


================
Comment at: clang/lib/Interpreter/WASM.cpp:79
+  int Result =
+      lld::wasm::link(LinkerArgs, llvm::outs(), llvm::errs(), false, false);
+  if (!Result)
----------------
sbc100 wrote:
> v.g.vassilev wrote:
> > sbc100 wrote:
> > > argentite wrote:
> > > > v.g.vassilev wrote:
> > > > > 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?
> > > > AFAIK we can't really `exec()` within Emscripten.
> > > 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?
> > 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?
> 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?
@argentite could we try @sbc100's proposal?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158140/new/

https://reviews.llvm.org/D158140



More information about the cfe-commits mailing list