sunho added a comment. In D130788#3732325 <https://reviews.llvm.org/D130788#3732325>, @sbc100 wrote:
> In D130788#3731232 <https://reviews.llvm.org/D130788#3731232>, @sunho wrote: > >> In D130788#3730533 <https://reviews.llvm.org/D130788#3730533>, @sbc100 wrote: >> >>> I'm not totally sure but I think the change is responsible for the >>> emscripten integration bot failing `InterpreterTest.CatchException`: >>> https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket/8807160007692150337/+/u/LLVM_regression/stdout >>> >>> [==========] Running 1 test from 1 test suite. >>> [----------] Global test environment set-up. >>> [----------] 1 test from InterpreterTest >>> [ RUN ] InterpreterTest.CatchException >>> JIT session error: Symbols not found: [ __gxx_personality_v0, >>> _ZSt9terminatev, _ZTVN10__cxxabiv117__class_type_infoE, >>> __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, >>> __cxa_free_exception, __cxa_throw ] >>> Failure value returned from cantFail wrapped call >>> Failed to materialize symbols: { (main, { _ZN16custom_exceptionC2EPKc, >>> __clang_call_terminate, _ZTI16custom_exception, _ZTS16custom_exception, >>> throw_exception }) } >>> UNREACHABLE executed at >>> /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm/include/llvm/Support/Error.h:786! >>> Stack dump without symbol names (ensure you have llvm-symbolizer in your >>> PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x2464413)[0x55cb14660413] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246236c)[0x55cb1465e36c] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x24648df)[0x55cb146608df] >>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fad2fab1980] >>> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fad2eb0de87] >>> /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fad2eb0f7f1] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x23f798f)[0x55cb145f398f] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x1e9de35)[0x55cb14099e35] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x1e9d597)[0x55cb14099597] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246d6be)[0x55cb146696be] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246e659)[0x55cb1466a659] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246ee40)[0x55cb1466ae40] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x247b2c3)[0x55cb146772c3] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x247ab42)[0x55cb14676b42] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246559c)[0x55cb1466159c] >>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fad2eaf0c87] >>> >>> /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x1e9ceda)[0x55cb14098eda] >>> >>> This started happening consistently after this change >>> https://chromium.googlesource.com/emscripten-releases/+/584b2f531314d1e70cd5ebadcce7e015a6215c9a. >>> The only CL in that list that looks related seems to be this one. >> >> Could you share the detailed build configuration of those bots? > > All the step should be visible here: > https://ci.chromium.org/ui/p/emscripten-releases/builders/ci/linux-test-suites/b8805531315340503553/steps > > The most relevant one I guess would be: > > https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket/8805531315340503553/+/u/Build_LLVM/stdout > > Here you can see LLVM being configured with: > > > subprocess.check_call(`/b/s/w/ir/cache/builder/emscripten-releases/cmake-3.21.3-linux-x86_64/bin/cmake > -G Ninja -DPython3_EXECUTABLE=/b/s/w/ir/cache/vpython/68bda9/bin/python > -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release > -DCMAKE_INSTALL_PREFIX=/b/s/w/ir/x/w/install > -DCMAKE_CXX_FLAGS=-stdlib++-isystem/b/s/w/ir/x/w/install/include/c++/v1 > "-DCMAKE_EXE_LINKER_FLAGS=-L/b/s/w/ir/x/w/install/lib -stdlib=libc++" > "-DCMAKE_SHARED_LINKER_FLAGS=-L/b/s/w/ir/x/w/install/lib -stdlib=libc++" > "-DCMAKE_MODULE_LINKER_FLAGS=-L/b/s/w/ir/x/w/install/lib -stdlib=libc++" > -DCMAKE_SYSROOT=/b/s/w/ir/cache/builder/emscripten-releases/sysroot_debian_stretch_amd64 > > -DCMAKE_C_COMPILER=/b/s/w/ir/cache/builder/v8/third_party/llvm-build/Release+Asserts/bin/clang > > -DCMAKE_CXX_COMPILER=/b/s/w/ir/cache/builder/v8/third_party/llvm-build/Release+Asserts/bin/clang++ > -DCMAKE_C_COMPILER_LAUNCHER=/b/s/w/ir/cache/goma/client/gomacc > -DCMAKE_CXX_COMPILER_LAUNCHER=/b/s/w/ir/cache/goma/client/gomacc > /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm > -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_INCLUDE_EXAMPLES=OFF > -DLLVM_BUILD_LLVM_DYLIB=OFF -DLLVM_LINK_LLVM_DYLIB=OFF > -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -DLLVM_ENABLE_BINDINGS=OFF > -DLLVM_TOOL_LTO_BUILD=OFF -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON > -DLLVM_TARGETS_TO_BUILD=host;WebAssembly -DLLVM_ENABLE_PROJECTS=lld;clang > -DLLVM_ENABLE_TERMINFO=0 -DLLVM_USE_CRT_RELEASE=MT -DLLVM_USE_CRT_DEBUG=MTd > -DCLANG_ENABLE_ARCMT=OFF -DCLANG_ENABLE_STATIC_ANALYZER=OFF > -DCLANG_REPOSITORY_STRING=https://github.com/llvm/llvm-project > -DLLVM_ENABLE_LLD=ON -DLLVM_ENABLE_ASSERTIONS=ON`, > cwd=`/b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out`) > > The code the drives the build is here: > https://chromium.googlesource.com/emscripten-releases/+/12ac1c00143f5a8a6722bdb8cca9e4515c2654d0/src/build.py#690 > > Note that we do use out own libc++ build (which is static I believe) but we > don't set LLVM_STATIC_LINK_CXX_STDLIB.. we inject it via generic cmake > flags: `-DCMAKE_CXX_FLAGS=-stdlib++-isystem=.. -DCMAKE_EXE_LINKER_FLAGS=-L... > -stdlib=libc++` (this works for the other cmake projects that we also build, > as well as llvm). Perhaps we should use be passing > `LLVM_STATIC_LINK_CXX_STDLIB`. Aha. If you are specifying static build like that, it wouldn't disable clang-repl build, thus it's destined to fail. You could try setting LLVM_STATIC_LINK_CXX_STDLIB. If that is not acceptable for some reason, we could make HAVE_CLANG_REPL_SUPPORT an option so that it can be disabled manually. > I'm curious through because things were working prior to this change.. and > stopped working after this change.. even though this change is apparently > targeted at fixing the exact issue that it seems to have caused for us. > Rather odd. It's actually an intended behaviour. I eliminated an existing workaround to circumvent the same failure which turned out to be not working in some out-of-tree system. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130788/new/ https://reviews.llvm.org/D130788 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
