On Wed, Jul 29, 2015 at 8:59 PM, Eric Fiselier <[email protected]> wrote: > 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? >
Yes, this patch works for me. Thank you! > > 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? > I actually support the idea of including LLVM CMake modules from libc++ CMake: the logic for building instrumented LLVM and building instrumented libc++ should better be listed in a single place, and be controlled by LLVM_USE_SANITIZER options: i.e. when we configure libc++ from compiler-rt, we should pass -DLLVM_USE_SANITIZER=Thread rather than -DCMAKE_CXX_FLAGS=-fsanitize=thread. It's not possible to do this right now, though (for instance we build two different versions of MSan-libc++), but I think I'd be able to work on that once your patch lands and the dust settles. > > 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] > -- Alexey Samsonov [email protected]
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
