Add host exception support check utility flag. This is needed to not run tests that require exception support in few buildbots that lacks related symbols for some reason.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm ok with this going in as-is, since it will help unblock other exception support work, as long as we include the todos.
clang/tools/clang-repl/ClangRepl.cpp | ||
---|---|---|
72–104 | Is this just a default JIT setup and a lookup of a symbol that we expect to find in-process? If so, then we should add a TODO to look for a cleaner approach (e.g. check via EPC directly if/when possible). |
Hello,
The new testcase added in this patch fails for me all the time.
I'm compiling on a linux RHEL 7 machine.
When I run the clang-repl command in the test I get
JIT session error: Symbols not found: [ _ZTIPKc ] error: Failed to materialize symbols: { (main, { _Z14checkExceptionv, $.incr_module_9.__inits.0, __orc_init_func.incr_module_9, r1 }) } error: Failed to materialize symbols: { (main, { __orc_init_func.incr_module_9 }) } clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl>
Any idea?
@uabelho Hi, that's a typeinfo symbol of libc++ abi. It's quite weird that __cxa_throw is availble while _ZTIPKc is not. Do you have some special setting regarding libc++ in your environment?
We compile with clang 8 on a RHEL7 machine, but since we then got too old libs we do
--gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler
since we have newer libs there. This is seen in the cmake command:
cmake command: CC='/proj/flexasic/app/llvm/8.0/bin/clang -march=corei7 --gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler' CXX='/proj/flexasic/app/llvm/8.0/bin/clang++ -march=corei7 --gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler' LDFLAGS='-Wl,-R/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64' PATH=/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin:$PATH /app/vbuild/RHEL7-x86_64/cmake/3.16.4/bin/cmake /repo/uabelho/main-github/llvm --debug-trycompile -G Ninja -DCMAKE_MAKE_PROGRAM=/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin/ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_INSTALL_PREFIX=/compiler-clang -DLLVM_APPEND_VC_REV=OFF -DLLVM_CCACHE_DIR=/repo/uabelho/.ccache/ -DLLVM_CCACHE_BUILD=ON -DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache -DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' -DLLVM_ENABLE_Z3_SOLVER=ON -DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 -DLLVM_ENABLE_LIBPFM=OFF -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF -DLLVM_ENABLE_LIBEDIT=OFF -DLLVM_STATIC_LINK_CXX_STDLIB=ON -DCLANG_ENABLE_ARCMT=OFF -DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF
Could it be something like that there is a mismatch somewhere so the support checks will use some libs but then the actual libs used when compiling/running is something else?
Thanks for the detailed information. I'm thining it's because of LLVM_STATIC_LINK_CXX_STDLIB=ON. The default method used by ORC for finding external symbol on linux is look up the symbols defined by the current process and dynamic libraries loaded so far using dlsym. Since libstdc++ was statically linked, some of the libstdc++ symbols might not be visible in symbol table. It's still weird that it has successfully found __cxa_throw though. (the log you showed says it has found __cxa_throw)
I'll try to reproduce the issue by tweaking LLVM_STATIC_LINK_CXX_STDLIB on my local machine and report back.
@uabelho The thing is we have to statically link libstdc++ in JIT stack, but this is not possible at the moment in many platforms. It's actually possible with a new generation linker called JITLink, but it has limited platform support. For now, I just sumbitted a patch disabling clang-repl build when LLVM_STATIC_LINK_CXX_STDLIB is turned on. This should resolve the build failure on your side. If you want to use clang-repl on your environment, it's actually possible to statically link libstdc++ on JIT side as JITLink is available on x86 linux. Please let me if you want me to dig into it.
Is this just a default JIT setup and a lookup of a symbol that we expect to find in-process? If so, then we should add a TODO to look for a cleaner approach (e.g. check via EPC directly if/when possible).