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