<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Reid, I think your breakdown makes a lot of sense. Generally I think instrumentation tools (profile & xray) could be grouped with the sanitizers. More broadly those are all "developer tool" libraries.<div class=""><br class=""></div><div class="">Pulling crt, builtins, and blocks into a separate top-level project is, IMO, the right goal.</div><div class=""><br class=""></div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 29, 2019, at 1:37 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Thanks for organizing the discussion and summarizing it. I haven't been involved, but it all seems like it's going in the right direction.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 29, 2019 at 10:10 AM Chris Bieneman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><div class="">There are also problems related to cross-runtime dependencies which have come up recently. Some of these problems can be addressed more cleanly with modern CMake generator expressions, and other issues may require a larger restructuring of code. For years there have been discussions thrown around about breaking the builtins libraries out of compiler-rt. Maybe now is the time to consider doing that.</div></div></blockquote><div class=""><br class=""></div><div class="">Why split out builtins from compiler-rt? They were the original compiler runtime library. Should we go the other direction instead? For a long time, I've wondered if we should have split the sanitizer runtimes out of compiler-rt. GCC maintains a forked copy of some of the sanitizer runtimes in a libsanitizer subdirectory next to libgcc:</div><div class=""><a href="https://github.com/gcc-mirror/gcc/tree/master/libsanitizer" class="">https://github.com/gcc-mirror/gcc/tree/master/libsanitizer</a></div><div class="">I think we put the sanitizers in compiler-rt mainly because it is a "compiler runtime", a runtime to which the compiler generates calls, but the same applies to libcxxabi, OpenMP, I assume libcl, and other things. The sanitizers are the biggest piece of compiler-rt by far, so maybe they deserve their own top level directory.</div><div class=""><br class=""></div><div class="">Here are the contents of compiler-rt/lib, with my categorizations:</div><div class=""><br class=""></div><div class="">Platform building blocks:<br class="">- crt<br class="">- builtins<br class="">- BlocksRuntime<br class=""><br class="">Instrumentation tools:<br class="">- profile<br class="">- xray<br class=""><br class="">Sanitizer or security things:<br class="">- cfi<br class="">- asan<br class="">- tsan<br class="">- ubsan<br class="">- ubsan_minimal<br class="">- dfsan<br class="">- fuzzer<br class="">- gwp_asan<br class="">- hwasan<br class="">- interception<br class="">- lsan<br class="">- msan<br class="">- safestack<br class="">- sanitizer_common<br class="">- stats<br class="">- scudo</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class="">All of the above said, I don't see any particularly strong reasons to change anything at the moment, but maybe you have a good reason to separate builtins and instrumentation that I haven't thought of.</div></div></div>
</div></blockquote></div><br class=""></div></body></html>