Emscripten: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf

[jeromelaban]

I'm re-opening an issue here regarding https://github.com/WebAssembly/binaryen/issues/2180, where the 1.39.4 release does not fix the sample below. How does one validate that Binaryen has been updated since the original issue was fixed? Thanks!

#include <setjmp.h>
#include <stdio.h>

typedef struct {
  jmp_buf* jmp;
} jmp_state;

void setjmp_func(jmp_state* s, int level) {
  jmp_buf* prev_jmp = s->jmp;
  jmp_buf c_jmp;

  if (level == 2) {
    longjmp(*(s->jmp), 1);
  }

  if (setjmp(c_jmp) == 0) {
    setjmp_func(s, level + 1);
  }
}

int main() { return 0; }

Built as follows:

emcc \
   test.cpp \
   -o test.wasm \
   -s SIDE_MODULE=1

[sbc100]

This example works fine for me on ToT.

How are you installing emscripten? Are you using the emsdk? You can have binaryen report the version to you by passing --version to any of the tools e.g. wasm-opt --version.

Can you post the output of the command (preferable with EMCC_DEBUG=1).

[jeromelaban]

I'm installing it this way:

git clone https://github.com/emscripten-core/emsdk
cd ~/emsdk
./emsdk install 1.39.4
./emsdk activate 1.39.4

Gives me:

~$ emcc --version
emcc (Emscripten gcc/clang-like replacement) 1.39.4 (commit c10e3e86e8ead9243473c7148beaa9261956123b)

and

~$ ~/emsdk/upstream/bin/wasm-opt --version
wasm-opt 1.39.1-52-g0c2b5b417

The version of wasm-opt does not seem to be aligned, is this expected ?

[jeromelaban]

Here is the full log:

$ EMCC_DEBUG=1 emcc \
>    test.cpp \
>    -o test.wasm \
>    -s SIDE_MODULE=1
shared:DEBUG: EM_CONFIG is located in /home/jay/.emscripten
shared:DEBUG: JAVA not defined in /home/jay/.emscripten, using "java"
cache:DEBUG: PID 8731 acquiring multiprocess file lock to Emscripten cache at /home/jay/.emscripten_cache
cache:DEBUG: done
cache:DEBUG: PID 8731 released multiprocess file lock to Emscripten cache at /home/jay/.emscripten_cache
shared:DEBUG: check tells us to use wasm backend
emcc:WARNING: invocation: /home/jay/emsdk/upstream/emscripten/emcc.py test.cpp -o test.wasm -s SIDE_MODULE=1  (in /tmp)
shared:DEBUG: successfully executed /home/jay/emsdk/upstream/bin/clang++ --version
root:DEBUG: Checking JS engine ['/home/jay/emsdk/node/12.9.1_64bit/bin/node']
shared:DEBUG: successfully executed /home/jay/emsdk/node/12.9.1_64bit/bin/node --version
shared:DEBUG: successfully executed /home/jay/emsdk/upstream/bin/llc --version
shared:INFO: (Emscripten: Running sanity checks)
shared:WARNING: java does not seem to exist, required for closure compiler, which is optional (define JAVA in /home/jay/.emscripten if you want it)
shared:WARNING: closure compiler will not be available
emcc:DEBUG: compiling to bitcode
emcc:DEBUG: emcc step "parse arguments and setup" took 0.07 seconds
cache:DEBUG: PID 8731 acquiring multiprocess file lock to Emscripten cache at /home/jay/.emscripten_cache/wasm-obj-pic
cache:DEBUG: done
emcc:DEBUG: compiling source file: test.cpp
shared:DEBUG: successfully executed /home/jay/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -D__EMSCRIPTEN_major__=1 -D__EMSCRIPTEN_minor__=39 -D__EMSCRIPTEN_tiny__=4 -D_LIBCPP_ABI_VERSION=2 -Dunix -D__unix -D__unix__ -Werror=implicit-function-declaration -Xclang -nostdsysteminc -Xclang -isystem/home/jay/emsdk/upstream/emscripten/system/include/libcxx -Xclang -isystem/home/jay/emsdk/upstream/emscripten/system/lib/libcxxabi/include -Xclang -isystem/home/jay/emsdk/upstream/emscripten/system/include/compat -Xclang -isystem/home/jay/emsdk/upstream/emscripten/system/include -Xclang -isystem/home/jay/emsdk/upstream/emscripten/system/include/libc -Xclang -isystem/home/jay/emsdk/upstream/emscripten/system/lib/libc/musl/arch/emscripten -Xclang -isystem/home/jay/emsdk/upstream/emscripten/system/local/include -std=c++03 -DEMSCRIPTEN test.cpp -Xclang -isystem/home/jay/emsdk/upstream/emscripten/system/include/SDL -c -o /tmp/emscripten_temp/test_0.o -fPIC -fvisibility=default -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr
emcc:DEBUG: emcc step "compile inputs" took 0.04 seconds
emcc:DEBUG: emcc step "process inputs" took 0.00 seconds
emcc:DEBUG: emcc step "calculate system libraries" took 0.00 seconds
emcc:DEBUG: linking: ['/tmp/emscripten_temp/test_0.o', '-L/home/jay/emsdk/upstream/emscripten/system/local/lib', '-L/home/jay/emsdk/upstream/emscripten/system/lib', '-L/home/jay/.emscripten_cache/wasm-obj-pic']
shared:DEBUG: successfully executed /home/jay/emsdk/upstream/bin/wasm-ld -o /tmp/emscripten_temp/test.wasm --allow-undefined --lto-O0 --whole-archive /tmp/emscripten_temp/test_0.o -L/home/jay/emsdk/upstream/emscripten/system/local/lib -L/home/jay/emsdk/upstream/emscripten/system/lib -L/home/jay/.emscripten_cache/wasm-obj-pic --no-whole-archive --import-memory --import-table -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --strip-debug --no-gc-sections --export-dynamic --export-all --export __wasm_call_ctors --export __data_end --export main --export malloc --export free --export setThrew --export __errno_location --export fflush -shared
emcc:DEBUG: emcc step "link" took 0.01 seconds
emcc:DEBUG: LLVM => JS
shared:DEBUG: saving debug copy emcc-0-base.wasm
Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf
cache:DEBUG: PID 8731 released multiprocess file lock to Emscripten cache at /home/jay/.emscripten_cache/wasm-obj-pic
Traceback (most recent call last):
  File "/home/jay/emsdk/upstream/emscripten/emcc.py", line 3704, in <module>
    sys.exit(run(sys.argv))
  File "/home/jay/emsdk/upstream/emscripten/emcc.py", line 2235, in run
    final = do_emscripten(final, target + '.mem')
  File "/home/jay/emsdk/upstream/emscripten/emcc.py", line 464, in do_emscripten
    emscripten.run(infile, outfile, memfile)
  File "/home/jay/emsdk/upstream/emscripten/emscripten.py", line 2779, in run
    return temp_files.run_and_clean(lambda: emscripter(
  File "/home/jay/emsdk/upstream/emscripten/tools/tempfiles.py", line 105, in run_and_clean
    return func()
  File "/home/jay/emsdk/upstream/emscripten/emscripten.py", line 2780, in <lambda>
    infile, outfile_obj, memfile, shared.NODE_JS, temp_files, shared.DEBUG)
  File "/home/jay/emsdk/upstream/emscripten/emscripten.py", line 2180, in emscript_wasm_backend
    metadata = finalize_wasm(temp_files, infile, outfile, memfile, DEBUG)
  File "/home/jay/emsdk/upstream/emscripten/emscripten.py", line 2325, in finalize_wasm
    stdout=subprocess.PIPE)
  File "/home/jay/emsdk/upstream/emscripten/tools/shared.py", line 2925, in run_binaryen_command
    ret = run_process(cmd, stdout=stdout).stdout
  File "/home/jay/emsdk/upstream/emscripten/tools/shared.py", line 188, in run_process
    result.check_returncode()
  File "/home/jay/emsdk/upstream/emscripten/tools/shared.py", line 168, in check_returncode
    raise Py2CalledProcessError(returncode=self.returncode, cmd=self.args, output=self.stdout, stderr=self.stderr)
tools.shared.Py2CalledProcessError: Command '['/home/jay/emsdk/upstream/bin/wasm-emscripten-finalize', '--detect-features', '--side-module', '--pass-arg=legalize-js-interface-export-originals', '/tmp/emscripten_temp/test.wasm', '-o', '/tmp/emscripten_temp/test.wasm.o.wasm']' returned non-zero exit status 1

[sbc100]

Thanks! I've produced this locally now.

[rohitsaini1995]

How can I take this fix into my emsdk llvm backend. As I am not getting the fix in updated emsdk version. Do I need to build binaryen from source.

[sbc100]

Sadly the fix is causes issues when integrated with emscripten. So it will need a followup, at which point it will land in emsdk.

[rohitsaini1995]

Is there any workaround for now to get past this error.?

[sbc100]

Not really.. you can compile statically (without -fPIC) but that might not work for I guess?

[rohitsaini1995]

Yeah, that's not gonna work for me. By when can I expect this fix.

[sbc100]

The binaryen change that should fix this issue is current being re-landed: https://github.com/WebAssembly/binaryen/pull/2542

Once that lands it will probably get rolled into the emscripten-releases repo within a few hours. So if all goes well it should happen today. No guarantees though, it was already reverted once and that could happen again if other issues show up.

[jeromelaban]

Looks like this issue has been incorrectly closed by brion/binaryen@f0a2e2c (fix is not working per https://github.com/WebAssembly/binaryen/pull/2542#issuecomment-568138614)

[kripken]

I think this is the interesting github permission model here... @brion has permissions in this repo, so a commit in another repo can close an issue. Reopening for investigation.

[hugoam]

What is the status on this ? It is supposed to have been fixed in binaryen ?
I've tried both tot-upstream and latest from emsdk without success so far.

[hugoam]

Alright, I finally figured out how to check that, and I found that Binaryen indeed hasn't been updated since 12 days ago with https://chromium.googlesource.com/emscripten-releases/+/3f6b0d9fec2c9f3a52936ad4a99f557a43aacf94 and it bumped it to https://github.com/WebAssembly/binaryen/commit/bd4cac987f19ee4f59b161a77b996ff1de46c4b9 so the commit right before the one that fixed this :'(
(which matches what wasm-opt --version reports: wasm-opt 1.39.1-92-gbd4cac987)

Is the process of bumping binaryen version manual ? If yes a bump would be nice so I can verify that this is fixed :)

Or is the process automatic and the bump is actually blocked by this ? https://github.com/WebAssembly/binaryen/pull/2542#issuecomment-568138614

[kripken]

@hugoam correct, yeah - changes roll automatically, unless they are blocked by something, which is what happened here. I think the relevant people have been on vacation so this hasn't gotten fixed yet, but I believe everyone should be back tomorrow, so I hope we can resolve this then.

[DierkDroth]

Hi, is there any chance this issue could be addressed any time soon? Thanks

[sbc100]

I'm looking at this today. Hopefully we reland the binaryen fix today.

[DierkDroth]

@sbc100 that would be much appreciated since @jeromelaban (Platform UNO) is waiting to get that fixed in order to deploy to a new build to us...

[sbc100]

Oh the binaryen side of this fix landed again: https://github.com/WebAssembly/binaryen/pull/2622

Hopefully it will stick this time.

[rohitsaini1995]

Is this https://github.com/WebAssembly/binaryen/pull/2622 available with latest emsdk i.e 1.39.6. Because I tried both emsdk install latest and emsdk install tot-upstream, still the issue occurs.

[sbc100]

The fix is not in 1.39.6 no. But it should be in tot.

Which version is tot installing for you? You need to run emsdk update-tags before tot gets updated.

You can tell which version of binaryen you have installed by running upstream/bin/wasm-opt --version.

The version should look something like this;

wasm-opt version 90 (version_90-26-g5ca79a71b)

This means binaryen version 90 + 26 additional commits. This fix landed 53 commits after version 90 so if it says less that 53 than you don't have a recent enough version.

We are planning on doing a new emscripten release ASAP that will include this change.

I'm also trying to land a regression test on the emscripten side to prevent this bug from creeping back: https://github.com/emscripten-core/emscripten/pull/9633