Assertion `gotIndex == INVALID_INDEX' failed

[Beuc]

Hi,

I ran into an assertion error when linking zlib.

Steps to reproduce:

wget http://prdownloads.sourceforge.net/libpng/zlib-1.2.11.tar.gz
tar xf zlib-1.2.11.tar.gz 
cd zlib-1.2.11/
emconfigure env CFLAGS="-O3" ./configure --prefix $(pwd)/destdir
make

Output:

...
emcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o libz.so.1.2.11 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo  -lc 
wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/lld/wasm/Symbols.cpp:115: void lld::wasm::Symbol::setGOTIndex(uint32_t): Assertion `gotIndex == INVALID_INDEX' failed.
Stack dump:
0.	Program arguments: /home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld -o libz.so.1.2.11 --allow-undefined --import-memory --import-table --lto-O0 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo -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 -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=16777216 --global-base=1024 --relocatable 
 #0 0x00007f3d675d69f4 PrintStackTraceSignalHandler(void*) (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6d79f4)
 #1 0x00007f3d675d473e llvm::sys::RunSignalHandlers() (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6d573e)
 #2 0x00007f3d675d6ca8 SignalHandler(int) (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6d7ca8)
 #3 0x00007f3d6a4a9730 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12730)
 #4 0x00007f3d66a547bb raise (/lib/x86_64-linux-gnu/libc.so.6+0x377bb)
 #5 0x00007f3d66a3f535 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22535)
 #6 0x00007f3d66a3f40f (/lib/x86_64-linux-gnu/libc.so.6+0x2240f)
 #7 0x00007f3d66a4d102 (/lib/x86_64-linux-gnu/libc.so.6+0x30102)
 #8 0x00000000006ac4fb (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld+0x6ac4fb)
 #9 0x00000000006c691b lld::wasm::GlobalSection::assignIndexes() (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld+0x6c691b)
#10 0x00000000006b1466 (anonymous namespace)::Writer::run() (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld+0x6b1466)
#11 0x00000000006adaaf lld::wasm::writeResult() (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld+0x6adaaf)
#12 0x0000000000690ae7 (anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld+0x690ae7)
#13 0x000000000068b6d8 lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld+0x68b6d8)
#14 0x000000000041eadb main (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld+0x41eadb)
#15 0x00007f3d66a4109b __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409b)
#16 0x000000000041e669 _start (/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld+0x41e669)
shared:ERROR: '/home/me/workdir/emtests/renpyweb/toolchain/emsdk/upstream/bin/wasm-ld -o libz.so.1.2.11 --allow-undefined --import-memory --import-table --lto-O0 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo -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 -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=16777216 --global-base=1024 --relocatable' failed (-6)
make: *** [Makefile:282: libz.so.1.2.11] Error 1

$ emcc --version
emcc (Emscripten gcc/clang-like replacement) 1.38.42 (commit da4900b83f6bce7511189b9307569d6c9c344e36)

[supernow]

I got this error ,too

[sbc100]

Certainly looks like an lld bug. Will try to reproduce locally.

[Beuc]

I got it again when linking SDL2_mixer 2.0.1 and freebidi 0.19.2.
Let me know if you're interested in more traces.

[sbc100]

Fix is in progress in https://reviews.llvm.org/D66784. As a workaround (assuming are you are not actually trying to use MAIN_MODULE/SIDE_MODULE) you can make sure you are building everything without -fPIC.

[Beuc]

Are there instructions on how to manually test this patch? (it is still waiting for review at LLVM)
(I tried getting rid of all -fPIC but apparently I missed one and the error doesn't tell me where)
Building Emscripten from Source is quite vague for "upstream", and I don't know how the official binaries are built.

[pmp-p]

same question there :)

[kripken]

Oh, what's missing from the docs in that link? It links to the upstream docs and it mentions the extra flag -DLLVM_ENABLE_PROJECTS=lld;clang.

[Beuc]

The upstream doc has like 50 project-specific options that one may or may not need (the previous fastcomp doc set 5 precise options). Each build requires at least one hour, each mistake requires a complete rebuild. Consequently I don't want to spend the week-end running builds and finding a working configuration by trial-and-error, I'd rather use a tested set of options -- preferably the one you use for official builds.
With the added insurance that errors I'll report will come from the patch and not from my build :)

[kripken]

Oh, yeah - LLVM does have a lot of options. But you don't need any, in most cases just a standard cmake build should work, so

mkdir mybuild
cd mybuild
cmake .. [extra flags from emscripten docs]
make -j8

If you do need any special flags to work around a local issue (like if the cmake step fails on something), then the LLVM docs can be very helpful. I don't think there's anything we can add in the emscripten docs, except to add the code snippet I just wrote, would that help?

[Beuc]

Thanks for the info!

This is typically the kind of steps where, if one is already familiar with the target system, things appear natural, but if one is new, one has to assemble information from numerous pages. Also the LLVM documentation is adamant about reading the full documentation before trying anything, which is daunting. So providing explicit instructions, or pointing to the official build scripts (which I didn't find in e.g. .circleci) would help.

In either case, IMHO, the needed information include:

• where to checkout llvm from (repository "llvm-project" - https://github.com/llvm/llvm-project.git)
• how to identify to version to checkout (no tags for v10.x - always build "master"?)
• clarify whether clang needs to be checked-out separately or not (since we had to that with fastcomp, and that's optional now AFAIU; there's a warning about that in the LLVM doc)
• clarify whether "make install" is required or if the build is intended to be used in-place (installing would require carefully specifying a working install prefix, most probably non-default)

The cmake instructions seems to target ../llvm, rather than ...
There's a missing starting quote in the current documentation (-DLLVM_ENABLE_PROJECTS=lld;clang').
The phrase "using something like -DLLVM_..." was implying there was more configuration work/fiddling to perform, but since this fortunately doesn't seem to be the case, let's leave it out :)

I'm compiling as we speak, I'll add more remarks if I find some.

[Beuc]

Possibly, mention that this requires at least 70GB build space and 2h compilation. If there's a simple way to lower these requirements, it would be good to note them.

It seems my LLVM is 10x slower than the Emscriten build when compiling SDL2, I guess I missed an option, possibly CMAKE_BUILD_TYPE=Release. I'd have to spend 2 more hours to test this hypothesis.

-j8 will require a huge amount of memory at the linking phase and the build will probably fail (even with -j1 linking clang filled my 16GB RAM), so I would recommend a more conservative value.

--

binaryen/wasm-opt gives me Unknown option '--asyncify' - the binaryen port doesn't fetch the right version (86 vs. 89).
This may be a bug in the current port file.
If not, we also need:

• how to identify the required binaryen version
• the need to specify the location of binaryen in emconfig with BINARYEN_ROOT

--

At last I can build my project for the first time, but the browser greets me with:
uncaught exception: could not load memory initializer http://localhost:8000/libz.raw.js.mem
This file is nowhere to be found. Though given all the above, I don't have a high confidence in my build.
I hope this emphasizes that testing a simple patch could be made smoother! ;)

[Beuc]

2 long builds and testings later I eventually refined to what I wanted to read from emscripten.org:

cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS='lld;clang' -DLLVM_TARGETS_TO_BUILD="host;WebAssembly" -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF

--

This particular issue sounds fixed, but I get several other errors in my project.
No more time to investigate this week :/