[libcxx] r243574 - Recommit r243503 "[libcxx] Cleanup CMake configuration and integrate with LLVM"

[Alexey Samsonov]

On Wed, Jul 29, 2015 at 8:59 PM, Eric Fiselier <eric at efcs.ca> 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 <eric at efcs.ca> 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 <vonosmas at gmail.com>
> 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 <vonosmas at gmail.com>
> 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 <kcc at google.com>
> wrote:
> >>>>
> >>>> Thanks, check-msan works for me again.
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jul 29, 2015 at 4:47 PM, Eric Fiselier <eric at efcs.ca> wrote:
> >>>>>
> >>>>> Reverted as r243593.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Alexey Samsonov
> >>> vonosmas at gmail.com
> >>
> >>
> >>
> >>
> >> --
> >> Alexey Samsonov
> >> vonosmas at gmail.com
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150730/d7a61f8d/attachment.html>