[clang-repl] Add host exception support check utility flag.

[sunho]

Summary

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.

[v.g.vassilev]

@lhames, this lgtm, what do you think?

[lhames]

Do we know why the bots are missing these symbols?

[lhames]

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).

[uabelho]

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?

[sunho]

@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?

[uabelho]

In D129242#3686610, @sunho wrote:

@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?

[sunho]

In D129242#3686713, @uabelho wrote:

In D129242#3686610, @sunho wrote:

@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.

[sunho]

@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.

[sunho]

https://reviews.llvm.org/D130788 this is the patch fyi.

[uabelho]

In D129242#3687968, @sunho wrote:

https://reviews.llvm.org/D130788 this is the patch fyi.

Great, the patch works for us. Thanks!

clang/tools/clang-repl/ClangRepl.cpp

 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
 
 static llvm::cl::list<std::string>
     ClangArgs("Xcc",
               llvm::cl::desc("Argument to pass to the CompilerInvocation"),
               llvm::cl::CommaSeparated);
 static llvm::cl::opt<bool> OptHostSupportsJit("host-supports-jit",
                                               llvm::cl::Hidden);
+static llvm::cl::opt<bool> OptHostSupportsException("host-supports-exception",
+                                                    llvm::cl::Hidden);
 static llvm::cl::list<std::string> OptInputs(llvm::cl::Positional,
                                              llvm::cl::desc("[code to run]"));
 
 static void LLVMErrorHandler(void *UserData, const char *Message,
                              bool GenCrashDiag) {
   auto &Diags = *static_cast<clang::DiagnosticsEngine *>(UserData);
 
   Diags.Report(clang::diag::err_fe_error_backend) << Message;
if (CI->getDiagnosticOpts().VerifyDiagnostics) {
     Errs = Client->getNumErrors();
 
     // The interpreter expects BeginSourceFile/EndSourceFiles to be balanced.
     Client->BeginSourceFile(CI->getLangOpts(), &CI->getPreprocessor());
   }
   return Errs ? EXIT_FAILURE : EXIT_SUCCESS;
 }
 
+// Check if the host environment supports c++ exception handling
+// by querying the existence of symbol __cxa_throw.
+static bool checkExceptionSupport() {
+  auto J = llvm::orc::LLJITBuilder().create();
+  if (!J) {
+    llvm::consumeError(J.takeError());
+    return false;
+  }
+
+  auto Interp = clang::Interpreter::create(std::move(CI));
+  if (!Interp) {
+    llvm::consumeError(Interp.takeError());
+    return false;
+  }
+
+  if (auto Err = Interp->ParseAndExecute("")) {
+    llvm::consumeError(std::move(Err));
+    return false;
+  }
+
+  auto Sym = Interp->getSymbolAddress("__cxa_throw");
+  if (!Sym) {
+    llvm::consumeError(Sym.takeError());
+    return false;
+  }
+
+  return true;
+}
+
 llvm::ExitOnError ExitOnErr;
 int main(int argc, const char **argv) {
   ExitOnErr.setBanner("clang-repl: ");
   llvm::cl::ParseCommandLineOptions(argc, argv);
 
   std::vector<const char *> ClangArgv(ClangArgs.size());
   std::transform(ClangArgs.begin(), ClangArgs.end(), ClangArgv.begin(),
                  [](const std::string &s) -> const char * { return s.data(); });
   llvm::InitializeNativeTarget();
   llvm::InitializeNativeTargetAsmPrinter();
 
   if (OptHostSupportsJit) {
     auto J = llvm::orc::LLJITBuilder().create();
     if (J)
       llvm::outs() << "true\n";
     else {
       llvm::consumeError(J.takeError());
       llvm::outs() << "false\n";
     }
     return 0;
   }
 
+  if (OptHostSupportsException) {
+    if (checkExceptionSupport())
+      llvm::outs() << "true\n";
+    else
+      llvm::outs() << "false\n";
+    return 0;
+  }
+
   // FIXME: Investigate if we could use runToolOnCodeWithArgs from tooling. It
   // can replace the boilerplate code for creation of the compiler instance.
   auto CI = ExitOnErr(clang::IncrementalCompilerBuilder::create(ClangArgv));
 
   // Set an error handler, so that any LLVM backend diagnostics go through our
   // error handler.
   llvm::install_fatal_error_handler(LLVMErrorHandler,
                                     static_cast<void *>(&CI->getDiagnostics()));