Hi Alexey, I have an updated patch that does not include "HandleLLVMOptions.cmake" . This file was giving us most of the trouble. I have already confirmed that this works around the TSAN issue pointed out earlier. Could you test this patch to see if you run into any more problems?
On Wed, Jul 29, 2015 at 10:58 PM, Eric Fiselier <[email protected]> wrote: >> Eric, what part of your change caused this behavior change? Probably, after >> you've started to execute LLVM CMake modules, >> you've modified link flags used to build shared objects, and now they are >> required to have no unresolved symbols? > > This is exactly what is happening. HandleLLVMOptions.cmake adds > "-Wl,-z,defs" on linux when LLVM_USE_SANITIZER is not specified. > We also pick up -ffunction-sections and -fdata-sections. What effect > do those have on building with sanitizers? > > > One of the main reasons for this patch was to make it easier for > libc++ to support sanitizer configurations. > I would like the libc++ build to support each sanitizer configuration. > Currently it seems like compiler-rt is better at > building libc++ with sanitizers than libc++ is. > > Would anybody be willing to help with: > A) Figuring out the proper flags for building and linking libc++ with > each sanitizer. > B) Moving some of the compiler-rt CMake logic for building libc++ into > libc++ if applicable. > > /Eric > > On Wed, Jul 29, 2015 at 8:54 PM, Alexey Samsonov <[email protected]> wrote: >> I've submitted r243599 that slightly improves things: now libcxx can be >> configured with "Clang+TSan", but the build fails with a bunch of >> "undefined reference to `__tsan_read8'" >> errors when we are trying to link libc++.so. >> >> Generally, we *don't* link in TSan runtime into shared objects - it should >> only be linked into the executable, and __tsan_* symbols should be >> left unresolved. Eric, what part of your change caused this behavior change? >> Probably, after you've started to execute LLVM CMake modules, >> you've modified link flags used to build shared objects, and now they are >> required to have no unresolved symbols? >> >> On Wed, Jul 29, 2015 at 5:21 PM, Alexey Samsonov <[email protected]> wrote: >>> >>> I think I've found the "problem", causing CMake identification of Clang >>> version. I will submit it shortly. >>> >>> On Wed, Jul 29, 2015 at 4:50 PM, Kostya Serebryany <[email protected]> wrote: >>>> >>>> Thanks, check-msan works for me again. >>>> >>>> >>>> >>>> On Wed, Jul 29, 2015 at 4:47 PM, Eric Fiselier <[email protected]> wrote: >>>>> >>>>> Reverted as r243593. >>> >>> >>> >>> >>> -- >>> Alexey Samsonov >>> [email protected] >> >> >> >> >> -- >> Alexey Samsonov >> [email protected]
cmake.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
