[cfe-dev] RFC: Place libs in Clang-dedicated directories (affects openmp, libcxx, libunwind, compiler-rt)

[Petr Hosek via cfe-dev]

On Sun, Mar 10, 2019 at 7:50 PM Brian Cain <brian.cain at gmail.com> wrote:

> On Mon, Feb 25, 2019 at 4:17 AM Petr Hosek via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Wed, Feb 20, 2019 at 6:14 PM Joel E. Denny <jdenny.ornl at gmail.com>
>> wrote:
>>
>>> My alternative to LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is the preceding
>>> bullets.  In other words, you wouldn't need to specify
>>> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR because it would effectively be
>>> always on (except the directories might be different than now if the
>>> version locking issue is important, as noted above).  Is that what
>>> you're asking?
>>>
>>
>> That would be my preference. I always hoped that
>> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR would eventually become the default. It
>> would be nice to finish the Darwin support so we can completely deprecate
>> the old layout, but I don't know how far along beanz is in his effort. We
>> should also update openmp to stop using the custom Android-specific runtime
>> layout.
>>
>> There's also the unresolved question of where should libc++ headers and
>> libraries go. Currently, in LLVM_ENABLE_PER_TARGET_RUNTIME_DIR we use the
>> resource dir, but some people expressed the opinion that we shouldn't be
>> using these for libc++ et al. since they're not version-locked to Clang.
>> This is different from what GCC does (e.g. GCC would use
>> $prefix/lib/gcc/x86_64-linux-gnu/8/libstdc++.a) and it's one of the reasons
>> why I used the resource dir for libc++ et al. when implementing
>> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR.
>>
>> So concretely, today LLVM_ENABLE_PER_TARGET_RUNTIME_DIR uses the
>> following layout:
>>
>> headers: $prefix/lib/clang/$version/include(/$triple)(/c++/v1)
>> libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext
>>
>> The alternative that doesn't use resource dir for libc++ would be the
>> following:
>>
>> compiler-rt:
>>   headers: $prefix/lib/clang/$version/include
>>   libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext
>>
>> libc++, libc++abi, libunwind:
>>   headers: $prefix/include/c++/v1
>>   libraries: $prefix/lib/$triple/$name.$ext
>>
>
> Petr,
>
> One thing I was considering tinkering with was producing additional,
> msan-enabled libs for libc++/libc++abi in test-release.sh and changing
> Clang's driver to look for those first when "-fsanitize=memory" and
> "GetCXXStdlibType(Args) == ToolChain::CST_Libcxx".  This should give folks
> who want to use MSan a much easier path to do so.  Does this make that
> design change easier?  Say, if libc++/abi were found by looking in
> "$prefix/lib/$triple/$name-msan.$ext" ?
>

This is something that's already supported and we use it in our toolchain.
Specifically, runtimes build allows building sanitized version of runtimes
<https://github.com/llvm/llvm-project/blob/master/llvm/runtimes/CMakeLists.txt#L513>,
the artifacts end up
<https://github.com/llvm/llvm-project/blob/master/llvm/runtimes/CMakeLists.txt#L530>
in  $prefix/lib/$triple/$sanitizer/$name.$ext. We use it to build
ASan-instrumented
versions
<https://github.com/llvm/llvm-project/blob/master/llvm/runtimes/CMakeLists.txt#L530>
of libc++, libc++abi and libunwind which we ship with our toolchain.

There's currently no support in the driver since sanitizers shouldn't
affect the ABI, so it's fine to link against the uninstrumented version and
then load the instrumented one at runtime.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190310/732bdeb3/attachment.html>