llvm dev - May 2017 - moving libfuzzer to compiler-rt?

On 9 May 2017 at 18:55, Kostya Serebryany <kcc at google.com>
wrote:
>
>
> On Tue, May 9, 2017 at 10:23 AM, Dan Liew <dan at su-root.co.uk>
wrote:
>>
>> > Does anyone see good reasons why libFuzzer should remain in llvm
repo
>> > (as
>> > opposed to moving it to compiler-rt)?
>>
>> Does moving LibFuzzer to compiler-rt imply that it is compiled as part
>> of compiler-rt and shipped with it?
>>
>> How does that fit with LibFuzzer's model of allowing the user to
>> provide their own `main()`.
>
>
> libFuzzer doesn't allow users to use their own main (not any more).
> Although I am not sure how that's related to moving libFuzzer
somewhere.
Oops. That shows how long it's been since I looked at the source code.

It was related in that if LibFuzzer was shipped as part of compiler-rt
I presumed we would need to supply both libraries to end users.
Given that this feature was removed it is a non-issue.

Again, after offline conversation with Chris Bieneman:

 - move to compiler-rt would be too complicated due to change in licenses
 - it would make much more sense to move to “tools” folder instead, for the
following reasons:
    * conceptually, it’s a tool, not a library
    * all other projects in “lib” depend on LLVM and can not build without LLVM,
libFuzzer does not
    * practically speaking, CMake has no way of knowing whether Clang is being
built when
      “lib” is compiled, yet it does know for projects in tools.

Using a freshly built clang for projects in “tools” is embarrassingly easy and
only requires a couple of lines
of configuration change.

Kostya, what about moving to “tools” then?
> On May 9, 2017, at 11:07 AM, Dan Liew <dan at su-root.co.uk> wrote:
> 
> On 9 May 2017 at 18:55, Kostya Serebryany <kcc at google.com
<mailto:kcc at google.com>> wrote:
>> 
>> 
>> On Tue, May 9, 2017 at 10:23 AM, Dan Liew <dan at su-root.co.uk>
wrote:
>>> 
>>>> Does anyone see good reasons why libFuzzer should remain in
llvm repo
>>>> (as
>>>> opposed to moving it to compiler-rt)?
>>> 
>>> Does moving LibFuzzer to compiler-rt imply that it is compiled as
part
>>> of compiler-rt and shipped with it?
>>> 
>>> How does that fit with LibFuzzer's model of allowing the user
to
>>> provide their own `main()`.
>> 
>> 
>> libFuzzer doesn't allow users to use their own main (not any more).
>> Although I am not sure how that's related to moving libFuzzer
somewhere.
> 
> Oops. That shows how long it's been since I looked at the source code.
> 
> It was related in that if LibFuzzer was shipped as part of compiler-rt
> I presumed we would need to supply both libraries to end users.
> Given that this feature was removed it is a non-issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170509/4982a436/attachment.html>

On Tue, May 9, 2017 at 1:56 PM, George Karpenkov <ekarpenkov at apple.com>
wrote:
> Again, after offline conversation with Chris Bieneman:
>
>  - move to compiler-rt would be too complicated due to change in licenses
>  - it would make much more sense to move to “tools” folder instead, for
> the following reasons:
>     * conceptually, it’s a tool, not a library
>     * all other projects in “lib” depend on LLVM and can not build without
> LLVM, libFuzzer does not
>     * practically speaking, CMake has no way of knowing whether Clang is
> being built when
>       “lib” is compiled, yet it does know for projects in tools.
>
> Using a freshly built clang for projects in “tools” is embarrassingly easy
> and only requires a couple of lines
> of configuration change.
>
> Kostya, what about moving to “tools” then?
>
Well, ok, this sounds cool.
But can we make one more step and try to preserve the code where it is, for
the sake of compatibility?
E.g. can we have the CMake in tools while still keeping the code in lib?
Or a link of some kind?

My worry is that there are already quite a few places that know where
libFuzzer code is,
and I don't control all of them.

And, finally, I really don't get why we can do something in tools and
can't
do the same in lib.
Or we simply don't want to do it to keep things simple?

--kcc


>
> On May 9, 2017, at 11:07 AM, Dan Liew <dan at su-root.co.uk> wrote:
>
> On 9 May 2017 at 18:55, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
> On Tue, May 9, 2017 at 10:23 AM, Dan Liew <dan at su-root.co.uk>
wrote:
>
>
> Does anyone see good reasons why libFuzzer should remain in llvm repo
> (as
> opposed to moving it to compiler-rt)?
>
>
> Does moving LibFuzzer to compiler-rt imply that it is compiled as part
> of compiler-rt and shipped with it?
>
> How does that fit with LibFuzzer's model of allowing the user to
> provide their own `main()`.
>
>
>
> libFuzzer doesn't allow users to use their own main (not any more).
> Although I am not sure how that's related to moving libFuzzer
somewhere.
>
>
> Oops. That shows how long it's been since I looked at the source code.
>
> It was related in that if LibFuzzer was shipped as part of compiler-rt
> I presumed we would need to supply both libraries to end users.
> Given that this feature was removed it is a non-issue.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170509/f5944eae/attachment.html>