<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 12, 2017, at 2:16 PM, Kostya Serebryany <<a href="mailto:kcc@google.com" class="">kcc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Jul 12, 2017 at 2:11 PM, George Karpenkov via llvm-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><span class="">> I really like the property of libFuzzer living in its own place so that<br class="">> it's easy to use without building the world<br class=""><br class=""></span>But it’s not: the implementation of the coverage instrumentation<br class="">is done in one of the sanitizers, so it’s impossible to just use libFuzzer without them.<br class=""></blockquote><div class=""><br class=""></div><div class="">Mmm. what do you mean? </div><div class="">libFuzzer implements it's own coverage hooks now. </div></div></div></blockquote><div><br class=""></div><div>I might be wrong here, but I’m definitely seeing “missing symbol” errors every now and then if none</div><div>of the sanitizers was linked (it seems to complain specifically about ubsan for some reason).</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Furthermore, I would think that almost all libFuzzer users would use a sanitizer while fuzzing.<br class=""></blockquote><div class=""><br class=""></div><div class="">Probably. </div><div class="">Although for equivalence fuzzing (aka differential fuzzing) sanitizers are not needed. </div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">I can see a few more benefits of moving to compiler-rt:<br class=""><br class="">1) It would enforce the property<br class="">that either sanitizers and libfuzzer are both in “runtimes”, or they are both aren’t.<br class="">Then we can naturally add a dependency from libFuzzer test to sanitizers using CMake.<br class="">Otherwise, adding a dependency from libfuzzer tests to sanitizers requires<br class="">hacky if/elses in CMake configuration (and we already have too many of those).<br class=""><br class="">2) Orthogonally to the moving-of-source-code discussion, I would like to move the generated library<br class="">to the folder where other clang libraries and sanitizers are.<br class="">That would considerably simplify toolchain installation problem (as we know that sanitizers are already installed<br class="">correctly in the toolchain) as well as simplifying driver logic for both Clang and Swift.<br class="">[Diverting even further, I think it would be beneficial to build a dynamic library as well as an archive,<br class="">and use that at least on Mac, where it can solve the linking issues discussed in<span class="Apple-converted-space"> </span><a href="https://github.com/google/sanitizers/issues/832" rel="noreferrer" target="_blank" class="">https://github.com/google/<wbr class="">sanitizers/issues/832</a>.<br class="">It would be also be much easier if the resulting dylib would be in the same folder where other sanitizers are, due to the fact<br class="">that we already have the code for setting the expected rpath on the produced binary].<br class=""><br class="">This move can of course be done from any source directory, as it’s just a matter of setting a target property.<br class="">Yet the logic for selecting the folder is a 20-30 lines chunk of CMake, which I would like to avoid copying,<br class="">and which we could otherwise just reuse from compiler-rt.<br class=""><br class="">3) As Chris Bieneman has previously mentioned in the beginning of this thread,<br class="">adding libFuzzer to the toolchain installation might be problematic under the current license,<br class="">which requires binary attribution.<br class="">Performing the move and resolving the licensing concern would solve that.<br class=""></blockquote><div class=""><br class=""></div><div class="">Good! :) </div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="HOEnZb"><div class="h5"><br class=""><br class="">> On Jul 12, 2017, at 1:27 PM, Justin Bogner <<a href="mailto:mail@justinbogner.com" class="">mail@justinbogner.com</a>> wrote:<br class="">><br class="">> Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> writes:<br class="">>> On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov via llvm-dev <<br class="">>><span class="Apple-converted-space"> </span><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">>>><br class="">>>> I already forgot why we decided not to move the code to compiler-rt.<br class="">>>><br class="">>>> This would solve at least this problem.<br class="">>>> Since we now have -fsanitize=fuzzer it will actually be pretty natural.<br class="">>>><br class="">>>><br class="">>>> Licensing concerns, compiler-rt has a different license.<br class="">>>><br class="">>>> BTW libFuzzer CMake has a crazy amount of hacks to work under Windows,<br class="">>>> where logic in many parts<br class="">>>> is entirely different, so any help on testing and fixing arising issues<br class="">>>> would be much appreciated.<br class="">>>> All I can do is to make a commit and then try to understand the response<br class="">>>> from a bots,<br class="">>>> which is not very efficient.<br class="">>>><br class="">>><br class="">>> I got volunteered to help with that, I'll try your patch.<br class="">>><br class="">>> There's more stuff to unpack in the rest of your email, though. I'd really<br class="">>> rather go to compiler-rt instead of runtimes. runtimes seems like it's<br class="">>> going the opposite direction from the monorepo efforts.<br class="">><br class="">> I don't see how runtimes is going either for- or against- the monorepo<br class="">> stuff. We really need a model like runtimes/ rather than a model like<br class="">> projects/ going forward regardless of where you find the code. This is<br class="">> necessary if we want to build cross-compiled compiler-rt libraries in<br class="">> any sort of sane way.<br class=""><br class="">______________________________<wbr class="">_________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a></div></div></blockquote></div></div></blockquote></div><br class=""></body></html>