[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-commits
Subject: Re: [libcxx] r243574 - Recommit r243503 "[libcxx] Cleanup CMake configuration and integrate with LLV
From: Alexey Samsonov <vonosmas () gmail ! com>
Date: 2015-07-30 18:47:45
Message-ID: CAFBZoY8ROM5RfpiWs6o3n=ScsEvo0+XU8oW-q3QOZiwUyqsZMw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Jul 29, 2015 at 8:59 PM, Eric Fiselier <eric@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@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@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@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@google.com>
> wrote:
> >>>>
> >>>> Thanks, check-msan works for me again.
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jul 29, 2015 at 4:47 PM, Eric Fiselier <eric@efcs.ca> wrote:
> >>>>>
> >>>>> Reverted as r243593.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Alexey Samsonov
> >>> vonosmas@gmail.com
> >>
> >>
> >>
> >>
> >> --
> >> Alexey Samsonov
> >> vonosmas@gmail.com
>
--
Alexey Samsonov
vonosmas@gmail.com
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 29, \
2015 at 8:59 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" \
target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alexey,<br> \
<br> I have an updated patch that does not include<br>
"HandleLLVMOptions.cmake" . This file was giving us most of the<br>
trouble. I have already confirmed that this works around the TSAN<br>
issue pointed out earlier. Could you test this patch to see if you run<br>
into any more problems?<br></blockquote><div><br></div><div>Yes, this patch works for \
me. Thank you!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div \
class="h5"><br> On Wed, Jul 29, 2015 at 10:58 PM, Eric Fiselier <<a \
href="mailto:eric@efcs.ca">eric@efcs.ca</a>> wrote:<br> >> Eric, what part \
of your change caused this behavior change? Probably, after you've started to \
execute LLVM CMake modules,<br> >> you've modified link flags used to build \
shared objects, and now they are required to have no unresolved symbols?<br> ><br>
> This is exactly what is happening. HandleLLVMOptions.cmake adds<br>
> "-Wl,-z,defs" on linux when LLVM_USE_SANITIZER is not specified.<br>
> We also pick up -ffunction-sections and -fdata-sections. What effect<br>
> do those have on building with \
sanitizers?<br></div></div></blockquote><div><br></div><div>I actually support the \
idea of including LLVM CMake modules from libc++ CMake:</div><div>the logic for \
building instrumented LLVM and building instrumented libc++ should better be \
listed</div><div>in a single place, and be controlled by LLVM_USE_SANITIZER \
options:</div><div>i.e. when we configure libc++ from compiler-rt, we should pass \
-DLLVM_USE_SANITIZER=Thread</div><div>rather than \
-DCMAKE_CXX_FLAGS=-fsanitize=thread. It's not possible to do this</div><div>right \
now, though (for instance we build two different versions of MSan-libc++), but \
I</div><div>think I'd be able to work on that once your patch lands and the dust \
settles.</div><div><br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
class="HOEnZb"><div class="h5"> > One of the main reasons for this patch was to \
make it easier for<br> > libc++ to support sanitizer configurations.<br>
> I would like the libc++ build to support each sanitizer configuration.<br>
> Currently it seems like compiler-rt is better at<br>
> building libc++ with sanitizers than libc++ is.<br>
><br>
> Would anybody be willing to help with:<br>
> A) Figuring out the proper flags for building and linking libc++ with<br>
> each sanitizer.<br>
> B) Moving some of the compiler-rt CMake logic for building libc++ into<br>
> libc++ if applicable.<br>
><br>
> /Eric<br>
><br>
> On Wed, Jul 29, 2015 at 8:54 PM, Alexey Samsonov <<a \
href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> wrote:<br> >> \
I've submitted r243599 that slightly improves things: now libcxx can be<br> \
>> configured with "Clang+TSan", but the build fails with a bunch \
of<br> >> "undefined reference to `__tsan_read8'"<br>
>> errors when we are trying to link libc++.so.<br>
>><br>
>> Generally, we *don't* link in TSan runtime into shared objects - it \
should<br> >> only be linked into the executable, and __tsan_* symbols should \
be<br> >> left unresolved. Eric, what part of your change caused this behavior \
change?<br> >> Probably, after you've started to execute LLVM CMake \
modules,<br> >> you've modified link flags used to build shared objects, \
and now they are<br> >> required to have no unresolved symbols?<br>
>><br>
>> On Wed, Jul 29, 2015 at 5:21 PM, Alexey Samsonov <<a \
href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> wrote:<br> \
>>><br> >>> I think I've found the "problem", causing \
CMake identification of Clang<br> >>> version. I will submit it shortly.<br>
>>><br>
>>> On Wed, Jul 29, 2015 at 4:50 PM, Kostya Serebryany <<a \
href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br> >>>><br>
>>>> Thanks, check-msan works for me again.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Wed, Jul 29, 2015 at 4:47 PM, Eric Fiselier <<a \
href="mailto:eric@efcs.ca">eric@efcs.ca</a>> wrote:<br> >>>>><br>
>>>>> Reverted as r243593.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Alexey Samsonov<br>
>>> <a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Alexey Samsonov<br>
>> <a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="gmail_signature"><div dir="ltr">Alexey Samsonov<br><a \
href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div> \
</div></div>
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic