This is an archive of the discontinued LLVM Phabricator instance.

[LibFuzzer] Refactor declaration of tests in CMake.
ClosedPublic

Authored by delcypher on May 26 2016, 3:46 PM.

Details

Summary

[LibFuzzer] Refactor declaration of tests in CMake.

Add a new CMake function (add_libfuzzer_test()) to simplify
declaration of executables for testing LibFuzzer and use it to
reorganise how tests are declared.

Note that configuration of the lit configuration files has been moved
as late as possible because we are going to need to disable some tests
for some platforms and we will need to propagate this information into
the lit configuration.

Diff Detail

Repository
rL LLVM

Event Timeline

delcypher updated this revision to Diff 58707.May 26 2016, 3:46 PM
delcypher retitled this revision from to [LibFuzzer] Refactor declaration of tests in CMake..
delcypher updated this object.
delcypher added reviewers: kcc, aizatsky.
kcc added inline comments.May 26 2016, 3:53 PM
lib/Fuzzer/test/CMakeLists.txt
31 ↗(On Diff #58707)

Let's start from not having this "NO_MAIN" complexity.
CustomMainTests is empty and could be safely removed.
The gunit unit test is a separate beast, one of its kind.

@kcc @aizatsky: To give you more context as to how these changes are going to be used I have some WIP patches that depend on this one:

  • fix weak linking issues on OSX:

https://github.com/delcypher/llvm/commit/63ba587cd1f94e1b7c29877f1f7afdff5efc477c

  • Disable building DFSan tests when host compiler doesn't support it

https://github.com/delcypher/llvm/commit/c316fb26a8def458b51120e8cbdbf190fa8d0479

With those changes LibFuzzer can be compiled and the tests can be built on OSX. There are still test failures but this one step closer to bringing LibFuzzer to OSX.

Failing Tests (7):
    LLVMFuzzer :: fuzzer-leak.test
    LLVMFuzzer :: fuzzer-oom.test
    LLVMFuzzer :: fuzzer-trace-pc.test
    LLVMFuzzer :: fuzzer-traces.test
    LLVMFuzzer-Unittest :: LLVMFuzzer-Unittest/FuzzerDictionary.ParseDictionaryFile
    LLVMFuzzer-Unittest :: LLVMFuzzer-Unittest/FuzzerDictionary.ParseOneDictionaryEntry
    LLVMFuzzer-Unittest :: LLVMFuzzer-Unittest/FuzzerMutate.ShuffleBytes2

  Expected Passes    : 35
  Unsupported Tests  : 1
  Unexpected Failures: 7
delcypher added inline comments.May 26 2016, 4:03 PM
lib/Fuzzer/test/CMakeLists.txt
31 ↗(On Diff #58707)

@kcc:

I kept "NO_MAIN" because

  • I presumed the intention was to add tests to CustomMainTests at some point in the future. Is this not the intention?
  • Using the NO_MAIN variant of add_libfuzzer_test() for the unit test is very useful because in a subsequent patch (https://github.com/delcypher/llvm/commit/63ba587cd1f94e1b7c29877f1f7afdff5efc477c) I am going to add logic to fix weak linking issues on OSX. If I don't use add_libfuzzer_test() for the unit test then I will have duplicate the logic that fixes the weak linking issue for the unit test which isn't desirable because I am trying to avoid as much boiler plate CMake code as possible.

It is your call but I would prefer to use add_libfuzzer_test() for the unit test so that my subsequent patch for weak linking is cleaner. What would you like to do?

kcc added inline comments.May 26 2016, 4:07 PM
lib/Fuzzer/test/CMakeLists.txt
31 ↗(On Diff #58707)

Yes, I hope to not need CustomMainTests in future you can safely delete that part.

Sure, please have as much code reuse as possible for gnuint test, but I think you can do it w/o thie NO_MAIN

delcypher updated this revision to Diff 58735.May 26 2016, 6:02 PM
  • Remove use of NO_MAIN in add_libfuzzer_test(). This has added some code duplication when handling the unit test.
  • Rebase
delcypher marked 3 inline comments as done.May 26 2016, 6:02 PM

@kcc : I've updated the patch and rebased. I noticed that when I rebased that the LibFuzzer tests are taking much longer to run (this is nothing to do with my patch). They used to take ~40 seconds on my machine now it takes roughly ~140 seconds. Is that intentional?

kcc accepted this revision.May 26 2016, 6:09 PM
kcc edited edge metadata.

LGTM, assuming this does not change the behavior of 'check-fuzzer'.
I wonder, how you can verify that.
In the past I remember cmake changes that caused us to not run some tests.
We've learned about those in a hard way...

They used to take ~40 seconds on my machine now it takes roughly ~140 seconds. Is that intentional?

Not intentional... On my box they still take 25 seconds...

This revision is now accepted and ready to land.May 26 2016, 6:09 PM

@kcc :

LGTM, assuming this does not change the behavior of 'check-fuzzer'.
I wonder, how you can verify that.
In the past I remember cmake changes that caused us to not run some tests.
We've learned about those in a hard way...

I verified by doing a completely fresh build every time (to avoid lit running executables built previously) and checking that lit reports the same number of tests being executed.

kcc added a comment.May 26 2016, 6:19 PM

Perfect.
And I've just reduced the test run-time (on my box) to 14 seconds.

In D20706#441867, @kcc wrote:

LGTM, assuming this does not change the behavior of 'check-fuzzer'.
I wonder, how you can verify that.
In the past I remember cmake changes that caused us to not run some tests.
We've learned about those in a hard way...

They used to take ~40 seconds on my machine now it takes roughly ~140 seconds. Is that intentional?

Not intentional... On my box they still take 25 seconds...

Okay FYI the slow down is introduced in r270942. For that commit if I run

bin/llvm-lit lib/Fuzzer/test/fuzzer.test
-- Testing: 1 tests, 1 threads --
PASS: LLVMFuzzer :: fuzzer.test (1 of 1)
Testing Time: 126.83s
  Expected Passes    : 1

on the previous commit

bin/llvm-lit lib/Fuzzer/test/fuzzer.test
-- Testing: 1 tests, 1 threads --
PASS: LLVMFuzzer :: fuzzer.test (1 of 1)
Testing Time: 3.63s
  Expected Passes    : 1

My configure line is

CC=/home/dan/dev/llvm-upstream/ninja_build/bin/clang CXX=/home/dan/dev/llvm-upstream/ninja_build/bin/clang++ cmake -DCMAKE_BUILD_TYPE=RELWITHDEBINFO  -DLLVM_USE_SANITIZER=Address -DLLVM_USE_SANITIZE_COVERAGE=YES  ../src/ && make check-fuzzer -j8

and the clang I'm building with is clang version 3.9.0 (trunk 270188) which is a bit old. I should probably rebuild clang and see if this is still observable.

kcc added a comment.May 26 2016, 7:03 PM

Is this linux or mac?

In D20706#441909, @kcc wrote:

Is this linux or mac?

This is Linux (Arch Linux - Linux 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016 x86_64 GNU/Linux). I am building libfuzzer and the tests with an old revision of clang though so I will rebuild clang and try again. It is probably worth noting that my version of libstdc++ is probably different than yours (it is the version that comes with gcc 5.3.0).

This revision was automatically updated to reflect the committed changes.
kcc added a comment.May 27 2016, 10:43 AM
In D20706#441909, @kcc wrote:

Is this linux or mac?

This is Linux (Arch Linux - Linux 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016 x86_64 GNU/Linux). I am building libfuzzer and the tests with an old revision of clang though so I will rebuild clang and try again. It is probably worth noting that my version of libstdc++ is probably different than yours (it is the version that comes with gcc 5.3.0).

Let's deal with it in a separate thread.
Since I don't see it on my box you'll have to do the initial investigation (just look at 'top' what test is running for so long)