================
@@ -711,6 +712,14 @@ llvm::Error Interpreter::Undo(unsigned N) {
}
llvm::Error Interpreter::LoadDynamicLibrary(const char *name) {
+#ifdef __EMSCRIPTEN__
+ void *handle = dlopen(name, RTLD_NOW | RTLD_GLOBAL);
+ if (!handle) {
+ llvm::errs() << dlerror() << '\n';
+ return llvm::make_error<llvm::StringError>("Failed to load dynamic
library",
+ llvm::inconvertibleErrorCode());
+ }
+#else
----------------
anutosh491 wrote:
Hi, thanks for the suggestion.
I did some surface level introspection on `DynamicLibrarySearchGenerator::Load`
and I see it calls dlopen internally but I think the handle is wrapped in a
DynamicLibrarySearchGenerator, which lets the ORC JIT symbol resolution system
look inside the .so for symbols during later getSymbolAddress(...) calls.
So even if DynamicLibrarySearchGenerator::Load(...) works under WASM (which it
might), it:
i) Creates a JITDylib search generator
ii) Which requires an ORC execution engine
iii) Which you are not using in the wasm path (we're using
WasmIncrementalExecutor instead)
So as per what I see DynamicLibrarySearchGenerator infrastructure creates
symbol generators for ORC JIT Dylibs, which isn’t used in the wasm execution
model. So while the underlying dlopen(...) mechanism is similar,
DynamicLibrarySearchGenerator wouldn’t integrate meaningfully unless the wasm
executor also moved to using ORC JIT infrastructure, which it currently doesn’t.
https://github.com/llvm/llvm-project/pull/133037
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
