[llvm-dev] moving libfuzzer to compiler-rt?

[Justin Bogner via llvm-dev]

Kostya Serebryany <kcc at google.com> writes:
> On Tue, Jul 11, 2017 at 7:02 PM, George Karpenkov <ekarpenkov at apple.com>
> wrote:
>
>> I’ve submitted a WIP PR: https://reviews.llvm.org/D35288
>>
>
> Thanks for working in this!
>
> One question: will it make sense to *copy* the code to the new location,
> work on it, then delete the code from the old location,
> instead of doing a move in a single commit?
> I don't expect any dramatic changes in the code structure during a few
> weeks, so 'copy' might be much simpler than 'move'.

I don't particularly like this approach - I think it will add more
complexity and potential for error than necessary. Whatever we end up
doing, I imagine doing it all in one go shouldn't lead to too much
trouble.

>> There remains a number of unsolved issues:
>>
>> 1) Naming: “runtimes” enforces LLVM naming convention.
>> The project name is formed by removing the “lib” prefix, and then that is
>> the main ninja target,
>> and check-PROJ_NAME is used for tests.
>> Thus for libfuzzer the choices for folder/target name/tests target name
>> become
>> `libfuzzer`/`fuzzer`/`check-fuzzer`.
>>
>> That is not optimal, but the situation is even worse if the folder is
>> called `libFuzzer`,
>> as targets rarely start with capital letters.
>>
>> 2) Dependencies: libFuzzer tests depend on ASAN and UBSAN.
>> It’s not possible to directly depend on other projects from “runtimes”, as
>> the code is compiled using
>> a recursive CMake invocation.
>> Those are also runtimes, and thus apparently it’s not possible to clearly
>> depend on them
>> in `runtimes/CMakeListst.txt` (though maybe the target list can be lazily
>> parsed for tests?)
>> The relevant problem was highlighted in a comment in
>> https://reviews.llvm.org/D33048
>>
>
> I already forgot why we decided not to move the code to compiler-rt.
> This would solve at least this problem.
> Since we now have -fsanitize=fuzzer it will actually be pretty natural.

So if you're willing to deal with the licensing stuff there's nothing
particularly wrong with the "move to compiler-rt" approach in a
technical sense, but I'm still pretty convinced the separate item in
runtimes thing makes more sense if we can get over the technical
challenges.

I really like the property of libFuzzer living in its own place so that
it's easy to use without building the world, and if it has its own
top-levelish cmake stuff this makes it much easier to use it with the
just-built clang. Adding this library into compiler-rt sort of
accomplishes this (because compiler-rt in runtimes already does the
right thing) but it feels like the wrong abstraction.