Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

lld::wasm::LinkingSection::writeBody(): Assertion `isec->getComdatName() == comdat' failed #45197

Open Quuxplusone opened 4 years ago

Quuxplusone commented 4 years ago
Bugzilla Link PR46227
Status NEW
Importance P normal
Reported by Claude Heiland-Allen (claude@mathr.co.uk)
Reported on 2020-06-06 11:21:29 -0700
Last modified on 2020-06-06 16:51:20 -0700
Version unspecified
Hardware PC Linux
CC llvm-bugs@lists.llvm.org, sbc@chromium.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Compiling Gem (a plugin for Pure-data) with Emscripten ("latest" as of today) fails at the link stage with an assertion failure in wasm-ld:

(very long link command omitted)
em++: warning: Assuming object file output in the absence of `-c`, based on output filename. Add with `-c` or `-r` to avoid this warning [-Wemcc]
em++: warning: ignoring unsupported linker flag: `-soname` [-Wlinkflags]
wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/lld/wasm/SyntheticSections.cpp:468: virtual void lld::wasm::LinkingSection::writeBody(): Assertion `isec->getComdatName() == comdat' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.  Program arguments: /home/empd/src/emsdk/upstream/bin/wasm-ld @/tmp/emscripten_6AmlHz.rsp 
 #0 0x00007fa590cc08c4 PrintStackTraceSignalHandler(void*) (/home/empd/src/emsdk/upstream/bin/../lib/libLLVM-11git.so+0x7df8c4)
 #1 0x00007fa590cbe50e llvm::sys::RunSignalHandlers() (/home/empd/src/emsdk/upstream/bin/../lib/libLLVM-11git.so+0x7dd50e)
 #2 0x00007fa590cc0a85 SignalHandler(int) (/home/empd/src/emsdk/upstream/bin/../lib/libLLVM-11git.so+0x7dfa85)
 #3 0x00007fa5940fb730 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12730)
 #4 0x00007fa5901ba7bb raise (/lib/x86_64-linux-gnu/libc.so.6+0x377bb)
 #5 0x00007fa5901a5535 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22535)
 #6 0x00007fa5901a540f (/lib/x86_64-linux-gnu/libc.so.6+0x2240f)
 #7 0x00007fa5901b3102 (/lib/x86_64-linux-gnu/libc.so.6+0x30102)
 #8 0x000000000078b4e2 lld::wasm::LinkingSection::writeBody() (/home/empd/src/emsdk/upstream/bin/wasm-ld+0x78b4e2)
 #9 0x000000000077ccaa lld::wasm::SyntheticSection::finalizeContents() (/home/empd/src/emsdk/upstream/bin/wasm-ld+0x77ccaa)
#10 0x0000000000776aa8 lld::wasm::(anonymous namespace)::Writer::run() (/home/empd/src/emsdk/upstream/bin/wasm-ld+0x776aa8)
#11 0x000000000076fda1 lld::wasm::writeResult() (/home/empd/src/emsdk/upstream/bin/wasm-ld+0x76fda1)
#12 0x0000000000754198 lld::wasm::(anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) (/home/empd/src/emsdk/upstream/bin/wasm-ld+0x754198)
#13 0x000000000074e6a7 lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&, llvm::raw_ostream&) (/home/empd/src/emsdk/upstream/bin/wasm-ld+0x74e6a7)
#14 0x0000000000487021 main (/home/empd/src/emsdk/upstream/bin/wasm-ld+0x487021)
#15 0x00007fa5901a709b __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409b)
#16 0x0000000000486aaa _start (/home/empd/src/emsdk/upstream/bin/wasm-ld+0x486aaa)
em++: error: '/home/empd/src/emsdk/upstream/bin/wasm-ld @/tmp/emscripten_6AmlHz.rsp' failed (-6)
make[3]: *** [Makefile:737: Gem.la] Error 1

To reproduce, on a system with debootstrap:

# on host system
sudo mkdir empd
sudo debootstrap --variant minbase buster empd/
sudo chroot empd/ /bin/bash
# inside chroot
mount -t proc proc /proc
mount -t tmpfs tmpfs /dev/shm/
apt install sudo git-core python2.7 nodejs build-essential cmake default-jre llvm clang autoconf automake libtool pkg-config
adduser --add_extra_groups empd
adduser empd sudo
su - empd
# as empd user
mkdir tmp
cd tmp/
git clone https://github.com/juj/emsdk.git
cd emsdk/
./emsdk install latest
./emsdk activate latest
. ./emsdk_env.sh 
cd ..
git clone --recursive https://github.com/claudeha/libpd.git
cd libpd
git checkout emscripten
cd pure-data
git remote add claudeha https://github.com/claudeha/pure-data.git
git fetch claudeha
git checkout claudeha/emscripten
cd ..
mkdir build
cd build
emcmake cmake .. -DPD_UTILS:BOOL=OFF -DCMAKE_BUILD_TYPE=Release
emmake make
cd ../../
git clone https://github.com/claudeha/Gem.git
cd Gem/
git checkout emscripten
./autogen.sh 
CXXFLAGS="-s USE_REGAL=1 -DREGAL_LOG=1 -DREGAL_LOG_ALL=1 -DREGAL_LOG_ONCE=1 -s USE_SDL=2 -s LEGACY_GL_EMULATION=0 -s ERROR_ON_UNDEFINED_SYMBOLS=0" CFLAGS="-s USE_REGAL=1 -DREGAL_LOG=1 -DREGAL_LOG_ALL=1 -DREGAL_LOG_ONCE=1 -s USE_SDL=2 -s LEGACY_GL_EMULATION=0 -s ERROR_ON_UNDEFINED_SYMBOLS=0" EMMAKEN_CFLAGS="-s USE_REGAL=1 -DREGAL_LOG=1 -DREGAL_LOG_ALL=1 -DREGAL_LOG_ONCE=1 -s USE_SDL=2 -s LEGACY_GL_EMULATION=0 -s ERROR_ON_UNDEFINED_SYMBOLS=0" GL_CFLAGS="-s USE_REGAL=1 -DREGAL_LOG=1 -DREGAL_LOG_ALL=1 -DREGAL_LOG_ONCE=1 -s USE_SDL=2 -s LEGACY_GL_EMULATION=0 -s ERROR_ON_UNDEFINED_SYMBOLS=0" GL_LIBS="-s USE_REGAL=1 -s USE_SDL=2 -s LEGACY_GL_EMULATION=0 -s ERROR_ON_UNDEFINED_SYMBOLS=0" GLU_CFLAGS="-s USE_REGAL=1 -DREGAL_LOG=1 -DREGAL_LOG_ALL=1 -DREGAL_LOG_ONCE=1 -s USE_SDL=2 -s LEGACY_GL_EMULATION=0 -s ERROR_ON_UNDEFINED_SYMBOLS=0" GLU_LIBS="-s USE_REGAL=1 -s USE_SDL=2 -s LEGACY_GL_EMULATION=0 -s ERROR_ON_UNDEFINED_SYMBOLS=0"  LIBS="-s USE_REGAL=1 -s USE_SDL=2 -s LEGACY_GL_EMULATION=0 -s ERROR_ON_UNDEFINED_SYMBOLS=0" emconfigure ./configure --prefix=${HOME}/opt --with-pd=${HOME}/src/libpd/pure-data/src --without-ALL --disable-multicontext --without-glew --without-glewmx --without-glut
emmake make -j $(nproc) -k
emmake make
Quuxplusone commented 4 years ago

Thanks for the report.

The crash should certainly be fixed. However you can make progress with this by disabled the building and using of shared libraries. I believe passing --disable-shared to configure will do this. emscripten doesn't support shared libraries per-say. At least not in the sense the autoconf expected.

Quuxplusone commented 4 years ago

Right, I do intend to link statically at the final stage, and the supposed shared object is really a bitcode file. But adding --disable-shared, which does avoid the crash, does not seem to give a useful build artifact (I get a 1kB libtool .la text file vs a 5MB .pd_linux (which is a renamed .so) file for a native build).

I'll see if I can patch Gem's build system to give a working static .a (really .bc) library, thanks for the idea. I'll report back here if I have success along those lines.

Quuxplusone commented 4 years ago

Just to add, that this did work about a year ago.

Quuxplusone commented 4 years ago

These days we prefer to use normal static libraries (.a files) rather than .bc files which is essentially combined object files.

This is more standard, plus it means we can use actual wasm object files rather than bitcode which is makes for faster builds. Plus we now have a linker that fully supports .a files.

I acknowledge that the technique you are using here used to work, and in general continues to work (once we fix this bug anyway).

However I stand by the statement that it would be better all around to use .a files in almost all cases. Fake .so files (combined objects files in .bc format) should be avoided when possible.

Regarding .la files, IIUC they are expected to be small, and are normally text files that reference the actual build artifact which should be a .a archive.

Quuxplusone commented 4 years ago

I managed to create a Gem.a in a hacky way (just copy/paste the failing shared library creation command and modify it to use ar instead; should be possible to fix the build system to do this for me somehow though I may need to ask the maintainers for help as I don't know much about the build system)

Then I needed to link my final artifact with

-Wl,--whole-archive Gem.a -Wl,--no-whole-archive

otherwise most of the code went missing (it uses C++ static initializers to register stuff for the main library setup function to call, so it isn't referenced by any code in the normal way). Thanks for your help!