Emscripten calls null GOT entry when side module loaded with `allowUndefined: true`

[hoodmane]

The following code example looks up GOT.__cxa_throw which is 0 and then calls it which throws TypeError: getWasmTableEntry(...) is not a function. Calling reportUndefinedSymbols or removing allowUndefined: true resolves the crash.

module.cpp

#include <stdexcept>

extern "C"
int cpp_func() { 
    try { 
        throw std::runtime_error(""); // crashes trying to throw this
    } catch (const std::exception &e) {
        return 0;
    }
    return 1;
} 

main.c

#include <dlfcn.h>
#include "stdio.h"
#include "emscripten.h"

typedef int (*InitFunc)(void);

int main(void) {
    EM_ASM({
        loadDynamicLibrary("module.so", { allowUndefined: true });
    });

    void* handle = dlopen("module.so", RTLD_NOW);
    printf("handle: %p\n", handle);
    if (!handle) {
        return 1;
    }
    InitFunc init_func = (InitFunc)dlsym(handle, "cpp_func");
    printf("init_func: %p\n", init_func);
    if (!init_func) {
        return 1;
    }
    int res = init_func(); // Crashes in init_func
    printf("res: %d\n", res);
    return 0;
}

build.sh

em++ -c module.cpp -fPIC -fexceptions -g2 -O2 
em++ module.o -o module.so \
    -sWASM_BIGINT -sSIDE_MODULE=1 -fexceptions -g2 -O2

emcc -c main.c -fPIC -fexceptions -g2 -O2 
emcc main.o -o main.js \
    -sWASM_BIGINT -sMAIN_MODULE=1 -fexceptions -g2 -O2

Then run with node main.js.

Version of emscripten/emsdk:
Checked on 3.1.52, 3.1.58 and tip of tree:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.62-git (0a0fa668c63cdaf14cfccb2ce62bc5afa46b4170)
clang version 19.0.0git (https:/github.com/llvm/llvm-project 0e62d5cf55479981da5e05e406bbca4afb3cdc4f)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/rchatham/Documents/programming/emsdk/upstream/bin
Build config: +assertions

[hoodmane]

I think this patch to GOTHandler.get fixes the problem:

--- a/src/library_dylink.js
+++ b/src/library_dylink.js
@@ -176,6 +176,16 @@ var LibraryDylink = {
         // correctly.
         rtn.required = true;
       }
+      var value = resolveGlobalSymbol(symName, true).sym;
+      if (!value) {
+        return rtn;
+      }
+      if (typeof value == 'function') {
+        /** @suppress {checkTypes} */
+        rtn.value = addFunction(value, value.sig);
+      } else if (typeof value == 'number') {
+        rtn.value = value;
+      }
       return rtn;
     }
   },

[sbc100]

We should probably add a test for this? I wonder if there is some way to build a test that doesn't depend on using EM_JS?

Do you know exactly which types of symbols are effected by this? Is __cxa_throw effected because its a JS symbol? Or would any symbol be similarly effected?

[hoodmane]

We should probably add a test for this?

+1 I'll add a test to #22053.

I wonder if there is some way to build a test that doesn't depend on using EM_JS?

loadDylibs sets allowUndefined: true and doesn't ever seem to call reportUndefinedSymbols(). I bet we can use that. I assume loadDylibs() is the code path we go through if we pass libsomething.so on the command line?

Do you know exactly which types of symbols are effected by this? would any symbol be similarly effected?

I am not sure. Many symbols don't seem to have this problem. I will investigate further and get back to you.

[hoodmane]

Nevermind, loadDylibs() does call reportUndefinedSymbols() so that doesn't work.

[hoodmane]

I think the first bad commit is emscripten-releases e4ea05676d38c899d486aeb1553af4a0b5432317

Roll llvm-project from b31414bf4f98 to a7f4576ff4e2 (58 revisions)

[hoodmane]

No wait that one is e4ea05676d38c899d486aeb1553af4a0b5432317 good first bad is the next commit 9063e25ecf39470a96689f3896ca5d4462928eb6:

Roll emscripten from f07067df82dd to 37055c7b57d0 (1 revision)

which is:

Update libcxx and libcxxabi to LLVM 18.1.2 (#21638)

This updates libcxx and libcxxabi to LLVM 18.1.2. Due to
llvm/llvm-project#65534 we need to update both
at the same time.

[hoodmane]

Reverting #21638 on top of the main branch has no conflicts and makes the problem go away. Any ideas why that might be @aheejin?