Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
@leonardchan would it be possible to break this up into 3 changes?
clang/cmake/caches/Fuchsia-stage2.cmake | ||
---|---|---|
123 | This shouldn't be needed. | |
140 | Don't we need the -static-libgcc flag here as well? |
Can do.
clang/cmake/caches/Fuchsia-stage2.cmake | ||
---|---|---|
123 | So while we do build builtins, this is actually needed to run builtins tests: https://github.com/llvm/llvm-project/blob/ad7e12226f6b1ebf91511899016cdfb29aa8919e/compiler-rt/test/CMakeLists.txt#L59 | |
140 | 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. |
clang/cmake/caches/Fuchsia-stage2.cmake | ||
---|---|---|
140 | 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. |
Split also into https://reviews.llvm.org/D109207 and https://reviews.llvm.org/D109208
clang/cmake/caches/Fuchsia-stage2.cmake | ||
---|---|---|
123 | We are already build builtins in a separate build so I think we should be running the tests there rather than building the twice. |
clang/cmake/caches/Fuchsia-stage2.cmake | ||
---|---|---|
123 | Ah, I didn't know that. Removed. |
This shouldn't be needed.