<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 2:11 PM, George Karpenkov via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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 class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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 <a href="https://github.com/google/sanitizers/issues/832" rel="noreferrer" target="_blank">https://github.com/google/<wbr>sanitizers/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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Jul 12, 2017, at 1:27 PM, Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>> wrote:<br>
><br>
> Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> writes:<br>
>> On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov via llvm-dev <<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">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">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><br>
</div></div></blockquote></div><br></div></div>