Always build libfuzzer
ClosedPublic

Authored by george.karpenkov on Fri, Apr 14, 2:22 PM.

Details

Summary

Hi,

There are two reasons why users might want to build libfuzzer:

  • To fuzz LLVM itself
  • To get the libFuzzer.a archive file, so that they can attach it to their code

Current CMake file only supports the first case: in order to build it, the user has to compile the entire LLVM repo with coverage flags (which is not even possible using e.g. default mac os clang).

The proposed change always builds libfuzzer, and supports the second use case if the specified flag is set.

Diff Detail

Repository
rL LLVM

Why do you need this change?
Anyone who wants to build libFuzzer.a can simply run lib/Fuzzer/build.sh.
libFuzzer is independent of the rest of LLVM (except that it requires the target to be built with LLVM's coverage instrumentation)
and so the build is also independent of LLVM.

the check-fuzzer (i.e. runninng libFuzzer tests), as you note, does require special flags and what's more important -- the fresh clang.

When/if we move to monorepo, I want to change these build rules to depend on freshly-built clang and then libFuzzer and its tests will be built/run by default.

(George works with me and Anna and he's trying to make libFuzzer more available to non-compiler folks.)

The point of this patch is to have something that can potentially be shipped with the compiler, and this also ensures that the version of libFuzzer is correct to use with that compiler. The current "recommended" way of using libFuzzer involves checking out the llvm repo and building a .a file of libFuzzer – we'd like to remove those steps and have the .a file be already a part of the compiler build.

kcc accepted this revision.Mon, Apr 17, 1:26 PM

George works with me and Anna

I've figured that out. Welcome George!

So, ok, I don't mind, as long as we all agree that this is a partial solution: we build libFuzzer.a but we don't test it in the default mode.

BTW, if you can figure out how to actually solve this problem (and to make the libFuzzer tests depend on the fresh clang) w/o waiting for the monorepo -- would be great!

This revision is now accepted and ready to land.Mon, Apr 17, 1:26 PM
In D32096#728508, @kcc wrote:

George works with me and Anna

I've figured that out. Welcome George!

So, ok, I don't mind, as long as we all agree that this is a partial solution: we build libFuzzer.a but we don't test it in the default mode.

Right, this is just a small incremental change, and there are further patches coming. The goal is to get libFuzzer as easy to use as e.g. AddressSanitizer.

BTW, if you can figure out how to actually solve this problem (and to make the libFuzzer tests depend on the fresh clang) w/o waiting for the monorepo -- would be great!

Sounds doable, this is what compiler-rt unit tests are already doing.

Sounds doable, this is what compiler-rt unit tests are already doing.

but they are in compiler-rt, while this is in llvm

This revision was automatically updated to reflect the committed changes.
kubamracek reopened this revision.Wed, Apr 19, 5:07 PM
This revision is now accepted and ready to land.Wed, Apr 19, 5:07 PM

@kcc Kostya, could you take a look at http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/7107/steps/build_Lld/logs/stdio ?
Seems like you are using a compiler extension which is not supported by one of the machines in our CI farm.
Is this extension required? What would be a reasonable way to check for its presence?
LLVM webpage currently claims that LLVM should be buildable with those (http://llvm.org/docs/GettingStarted.html#software)

There is another failure on http://green.lab.llvm.org/green/job/clang-stage1-configure-RA_build/33461/console

Thanks!

Currently blocked by D32312 and D32311.

This revision was automatically updated to reflect the committed changes.

Whitelisting allowed systems due to too many build failures on obscure architectures.
The new file exhibits old behavior (build on demand) for all systems except for mac os and linux.

kubamracek reopened this revision.Fri, Apr 21, 3:38 PM
This revision is now accepted and ready to land.Fri, Apr 21, 3:38 PM
This revision was automatically updated to reflect the committed changes.