[PATCH] D109199: [compiler-rt][Fuchsia] Support building + running compiler-rt tests on fuchsia's host toolchain

Leonard Chan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 2 16:51:45 PDT 2021


leonardchan added inline comments.


================
Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:141
+    set(RUNTIMES_${target}_SANITIZER_COMMON_TEST_TARGET_CFLAGS "--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+    set(RUNTIMES_${target}_TSAN_TEST_TARGET_CFLAGS "--unwindlib=libunwind" CACHE STRING "")
+    set(RUNTIMES_${target}_LLVM_TOOLS_DIR "${CMAKE_BINARY_DIR}/bin" CACHE BOOL "")
----------------
leonardchan wrote:
> phosek wrote:
> > Don't we need the `-static-libgcc` flag here as well?
> When testing locally, there was actually a tsan test that wasn't working if `-static-libgcc` was here. I can try to reproduce it. I believe it had to do with static linking in an archive, but a particular object file in that archive wasn't getting linked in which changed some runtime logic and caused the test to fail.
Oh ok. Disregard my last explanation. So the test is `compiler-rt/test/tsan/Linux/check_memcpy.c`, and the actual reason it failed is because the test just checks to make sure calls to `memcpy/memset` are not used at all (since tsan should intercept them and replace them with its own functions/code).

The issue is that if we statically link in an uninstrumented libunwind, then the test will fail bc it will find memcpy/set calls in that libunwind code. Removing the `-static-libgcc` seems to instead opt for dynamically linking against libunwind.so, and not linking in any uninstrumented code. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109199/new/

https://reviews.llvm.org/D109199



More information about the llvm-commits mailing list