<div dir="ltr"><div dir="ltr">On Sun, Mar 10, 2019 at 7:50 PM Brian Cain <<a href="mailto:brian.cain@gmail.com">brian.cain@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Feb 25, 2019 at 4:17 AM Petr Hosek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Feb 20, 2019 at 6:14 PM Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" target="_blank">jdenny.ornl@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My alternative to LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is the preceding<br>
bullets.  In other words, you wouldn't need to specify<br>
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR because it would effectively be<br>
always on (except the directories might be different than now if the<br>
version locking issue is important, as noted above).  Is that what<br>
you're asking?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So concretely, today LLVM_ENABLE_PER_TARGET_RUNTIME_DIR uses the following layout:</div><div><br></div><div><div>headers: $prefix/lib/clang/$version/include(/$triple)(/c++/v1)</div><div>libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext</div></div><div><br></div><div>The alternative that doesn't use resource dir for libc++ would be the following:</div><div><br></div><div><div>compiler-rt:</div><div>  headers: $prefix/lib/clang/$version/include</div><div>  libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext</div><div><br></div><div>libc++, libc++abi, libunwind:</div><div>  headers: $prefix/include/c++/v1</div><div>  libraries: $prefix/lib/$triple/$name.$ext</div><div></div></div></div></div></div></div></blockquote></div><div><br></div><div>Petr,</div><div><br></div><div>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" ?</div></div></div></blockquote><div><br></div><div>This is something that's already supported and we use it in our toolchain. Specifically, runtimes build allows <a href="https://github.com/llvm/llvm-project/blob/master/llvm/runtimes/CMakeLists.txt#L513">building sanitized version of runtimes</a>, the artifacts <a href="https://github.com/llvm/llvm-project/blob/master/llvm/runtimes/CMakeLists.txt#L530">end up</a> in  $prefix/lib/$triple/$sanitizer/$name.$ext. We use it to build <a href="https://github.com/llvm/llvm-project/blob/master/llvm/runtimes/CMakeLists.txt#L530">ASan-instrumented versions</a> of libc++, libc++abi and libunwind which we ship with our toolchain.</div><div><br></div><div>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.</div></div></div>