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

Sam Clegg via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 23 08:58:23 PDT 2023


sbc100 added a comment.

ood idea after all. Is there a suitable place where we could mo



================
Comment at: clang/lib/Interpreter/WASM.cpp:79
+  int Result =
+      lld::wasm::link(LinkerArgs, llvm::outs(), llvm::errs(), false, false);
+  if (!Result)
----------------
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?


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