Atomics issue when using latest-upstream

[Dylan Staley]

Hello! I recently heard about the new WebAssembly backend, and wanted to give it a try to compare against the fastcomp backend. I've successfully compiled this project using `latest`, but when I switch to `latest-upstream` I get the following issue during linking:

```

wasm-ld: error: 'atomics' feature is used by d1_lib.o, so --shared-memory must be used

wasm-ld: error: Target feature 'atomics' used in d1_lib.o is disallowed by ConcurrentScheduler.cpp.o. Use --no-check-features to suppress.

```

The actual command that failed was:

```

shared:ERROR: '/home/staley_dylan/emsdk/upstream/bin/wasm-ld -o /tmp/emscripten_temp_DthpaW/td_wasm.wasm --allow-undefined --import-memory --import-table --lto-O0 CMakeFiles/td_wasm.dir/td/telegram/td_emscripten.cpp.o libtdjson_static.a tdactor/libtdactor.a libtdjson_private.a libtdclient.a libtdcore.a tdnet/libtdnet.a ../crypto/lib/libssl.a tddb/libtddb.a tdactor/libtdactor.a tdutils/libtdutils.a sqlite/libtdsqlite.a ../crypto/lib/libcrypto.a /home/staley_dylan/.emscripten_cache/wasm-obj/libz.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc.a /home/staley_dylan/.emscripten_cache/wasm-obj/libcompiler_rt.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc-wasm.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc++-noexcept.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc++abi.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc-extras.a /home/staley_dylan/.emscripten_cache/wasm-obj/libdlmalloc.a /home/staley_dylan/.emscripten_cache/wasm-obj/libpthreads_stub.a /home/staley_dylan/.emscripten_cache/wasm-obj/libcompiler_rt_wasm.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc_rt_wasm.a -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --export __wasm_call_ctors --export __data_end --export main --export malloc --export free --export setThrew --export __errno_location --export htonl --export htons --export ntohs --export emscripten_builtin_memalign --export memalign --export _get_environ --export strlen --export _get_tzname --export _get_daylight --export _get_timezone --export emscripten_builtin_free -z stack-size=5242880 --initial-memory=16777216 --no-entry --global-base=1024' failed (1)

```

I assume this is something to do with shared memory support in WASM, but I haven't changed the configuration between a successful compile on `latest` and this failing one on `latest-upstream`. Does anyone have any idea? For reference, I'm trying to compile TdLib (https://github.com/tdlib/td).

[Mehdi Sabwat]

Hi, iirc you need to compile all objects with pthread enabled if you want to be able to link them together.

Will let you know if I find the confirmation...

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/aa04d445-70b5-4227-92b8-838df0070440%40googlegroups.com.

[Mehdi Sabwat]

I think it's there, https://reviews.llvm.org/D59625 . The backend seems to disallow linking with objects that use atomics features and are not tagged as such. That's how I have understood it. I fixed it in my build by adding pthread to my CFLAGS.


You don't seem to have CFLAGS so prepending cmake with CFLAGS="-pthread" should do the trick.


Let us know if it works :)


[Dylan Staley]

By adding the pthreads flag, will that change the behavior of the generated WASM module? I know that browsers like Chrome have experimental support for webassembly threads, but I'm aiming for a WASM module that works in older versions of Chrome as well.

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/tdjKEcKXXC8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/977d6ddf-d05b-40c5-a27d-37094d096252%40googlegroups.com.

[Thomas Lively]

Hi Dylan,

Here's what these errors mean in more detail.

wasm-ld: error: 'atomics' feature is used by d1_lib.o, so --shared-memory must be used

This one means that `dl_lib.o` was compiled with -pthread already (-pthread enables the 'atomics' feature), so its atomic operations have been lowered to real atomic WebAssembly instructions. However, because you're not passing -pthread at link time, the linker tries to produce a module with an unshared memory, which would make those atomic instructions invalid.

wasm-ld: error: Target feature 'atomics' used in d1_lib.o is disallowed by ConcurrentScheduler.cpp.o. Use --no-check-features to suppress.

This line tells us that ConcurrentScheduler.cpp.o was compiled without -pthread, which means its atomic operations were lowered to non-atomic WebAssembly instruction because the atomics feature was not enabled. That means that ConcurrentScheduler.cpp.o is not safe to link with dl_lib.o because the resulting program would not be thread-safe, even if the program was thread-safe at the source level. When using the LLVM backend, the wasm-ld linker helpfully recognizes this error and does not let you link an unsafe program. Fastcomp would just silently link your program into a thread-unsafe binary.

As Mehdi said, you can either make sure to use -pthread when building all your objects and libraries and at link time to get a properly thread-safe binary out, or alternatively you can make sure not to pass -pthread for any of the objects and libraries to get a single-threaded version of the binary that will run on any engine.

Let me know if I you want more detail on anything :)

You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2Bu72ZnbstT4XzQs7uMszj5%2BX%2BCoAsZy4ggiBu0ujOt9UwvOuQ%40mail.gmail.com.

[Mehdi Sabwat]

Hi Thomas,

Thank you for your answer it seems the difference between -s USE_PTHREADS=1 and -pthread lies within the JS code generation. But I am not sure.

My case is I am cross compiling a library that I will use as a module for a main.c, the main file will be compiled and linked with -s USE_PTHREADS=1 and other options (WEBGL, PTHREAD_PROXY etc...), do I need to compile all the dependencies with -s USE_PTHREADS=1 or is -pthread enough?

Thanks !

Regards

On Wednesday, July 24, 2019 at 11:55:07 PM UTC+2, Thomas Lively wrote:

Hi Dylan,

Here's what these errors mean in more detail.

wasm-ld: error: 'atomics' feature is used by d1_lib.o, so --shared-memory must be used

This one means that `dl_lib.o` was compiled with -pthread already (-pthread enables the 'atomics' feature), so its atomic operations have been lowered to real atomic WebAssembly instructions. However, because you're not passing -pthread at link time, the linker tries to produce a module with an unshared memory, which would make those atomic instructions invalid.

wasm-ld: error: Target feature 'atomics' used in d1_lib.o is disallowed by ConcurrentScheduler.cpp.o. Use --no-check-features to suppress.

This line tells us that ConcurrentScheduler.cpp.o was compiled without -pthread, which means its atomic operations were lowered to non-atomic WebAssembly instruction because the atomics feature was not enabled. That means that ConcurrentScheduler.cpp.o is not safe to link with dl_lib.o because the resulting program would not be thread-safe, even if the program was thread-safe at the source level. When using the LLVM backend, the wasm-ld linker helpfully recognizes this error and does not let you link an unsafe program. Fastcomp would just silently link your program into a thread-unsafe binary.

As Mehdi said, you can either make sure to use -pthread when building all your objects and libraries and at link time to get a properly thread-safe binary out, or alternatively you can make sure not to pass -pthread for any of the objects and libraries to get a single-threaded version of the binary that will run on any engine.

Let me know if I you want more detail on anything :)

On Wed, Jul 24, 2019 at 2:41 PM Dylan Staley <stale...@gmail.com> wrote:

By adding the pthreads flag, will that change the behavior of the generated WASM module? I know that browsers like Chrome have experimental support for webassembly threads, but I'm aiming for a WASM module that works in older versions of Chrome as well.

On Wed, Jul 24, 2019, 2:34 PM Mehdi Sabwat <mehdi...@gmail.com> wrote:

I think it's there, https://reviews.llvm.org/D59625 . The backend seems to disallow linking with objects that use atomics features and are not tagged as such. That's how I have understood it. I fixed it in my build by adding pthread to my CFLAGS.


You don't seem to have CFLAGS so prepending cmake with CFLAGS="-pthread" should do the trick.


Let us know if it works :)


On Wednesday, July 24, 2019 at 11:04:29 PM UTC+2, Dylan Staley wrote:

Hello! I recently heard about the new WebAssembly backend, and wanted to give it a try to compare against the fastcomp backend. I've successfully compiled this project using `latest`, but when I switch to `latest-upstream` I get the following issue during linking:

```

wasm-ld: error: 'atomics' feature is used by d1_lib.o, so --shared-memory must be used

wasm-ld: error: Target feature 'atomics' used in d1_lib.o is disallowed by ConcurrentScheduler.cpp.o. Use --no-check-features to suppress.

```

The actual command that failed was:

```

shared:ERROR: '/home/staley_dylan/emsdk/upstream/bin/wasm-ld -o /tmp/emscripten_temp_DthpaW/td_wasm.wasm --allow-undefined --import-memory --import-table --lto-O0 CMakeFiles/td_wasm.dir/td/telegram/td_emscripten.cpp.o libtdjson_static.a tdactor/libtdactor.a libtdjson_private.a libtdclient.a libtdcore.a tdnet/libtdnet.a ../crypto/lib/libssl.a tddb/libtddb.a tdactor/libtdactor.a tdutils/libtdutils.a sqlite/libtdsqlite.a ../crypto/lib/libcrypto.a /home/staley_dylan/.emscripten_cache/wasm-obj/libz.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc.a /home/staley_dylan/.emscripten_cache/wasm-obj/libcompiler_rt.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc-wasm.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc++-noexcept.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc++abi.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc-extras.a /home/staley_dylan/.emscripten_cache/wasm-obj/libdlmalloc.a /home/staley_dylan/.emscripten_cache/wasm-obj/libpthreads_stub.a /home/staley_dylan/.emscripten_cache/wasm-obj/libcompiler_rt_wasm.a /home/staley_dylan/.emscripten_cache/wasm-obj/libc_rt_wasm.a -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --export __wasm_call_ctors --export __data_end --export main --export malloc --export free --export setThrew --export __errno_location --export htonl --export htons --export ntohs --export emscripten_builtin_memalign --export memalign --export _get_environ --export strlen --export _get_tzname --export _get_daylight --export _get_timezone --export emscripten_builtin_free -z stack-size=5242880 --initial-memory=16777216 --no-entry --global-base=1024' failed (1)

```

I assume this is something to do with shared memory support in WASM, but I haven't changed the configuration between a successful compile on `latest` and this failing one on `latest-upstream`. Does anyone have any idea? For reference, I'm trying to compile TdLib (https://github.com/tdlib/td).

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/tdjKEcKXXC8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to emscripten-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/977d6ddf-d05b-40c5-a27d-37094d096252%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Thomas Lively]

-pthread and -s USE_PTHREADS should be identical. If they are not that is a bug we should look into. If you could file an issue on the Emscripten repository with details that would be great.

Either flag should work fine for compiling dependencies.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/d246edfc-c639-4e14-a544-e3b5406ffebc%40googlegroups.com.

[Mehdi Sabwat]

I am sorry I wasn't clear, I didn't mean there was a difference. I was just wondering if...

Thanks for your answer :)

Cheers!

To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/977d6ddf-d05b-40c5-a27d-37094d096252%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2Bu72ZnbstT4XzQs7uMszj5%2BX%2BCoAsZy4ggiBu0ujOt9UwvOuQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/d246edfc-c639-4e14-a544-e3b5406ffebc%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CC638F3B-AC30-4033-9D04-537941D2A418%40google.com.