gecko-dev/tools/fuzzing/moz.build

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

30 lines
624 B
Plaintext
Raw Normal View History

# -*- Mode: python; c-basic-offset: 4; indent-tabs-mode: nil; tab-width: 40 -*-
# vim: set filetype=python:
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
DIRS += [
'interface',
Bug 1431090 - Prepare tools/fuzzing/ to be used with JS_STANDALONE. r=froydnj This patch adjusts tools/fuzzing/ in such a way that the relevant parts can be reused in the JS engine. Changes in detail include: * Various JS_STANDALONE checks to exclude parts that cannot be included in those builds. * Turn LibFuzzerRegistry and LibFuzzerRunner into generic FuzzerRegistry and FuzzerRunner classes and use them for AFL as well. Previously, AFL was piggy-backing on gtests which was kind of an ugly solution anyway (besides that it can't work in JS). Now more code like registry and harness is shared between the two and they follow almost the same call paths and entry points. AFL macros in FuzzingInterface have been rewritten accordingly. This also required name changes in various places. Furthermore, this unifies the way, the fuzzing target is selected, using the FUZZER environment variable rather than LIBFUZZER (using LIBFUZZER in browser builds will give you a deprecation warning because I know some people are using this already and need time to switch). Previously, AFL target had to be selected using GTEST_FILTER, so this is also much better now. * I had to split up FuzzingInterface* such that the STREAM parts are in a separate set of files FuzzingInterfaceStream* because they use nsStringStream which is not allowed to be included into the JS engine even in a full browser build (error: "Using XPCOM strings is limited to code linked into libxul."). I also had to pull FuzzingInterface.cpp (the RAW part only) into the header and make it static because otherwise, would have to make not only separate files but also separate libraries to statically link to the JS engine, which seemed overkill for a single small function. The streaming equivalent of the function is still in a cpp file. * LibFuzzerRegister functions are now unique by appending the module name to avoid redefinition errors. MozReview-Commit-ID: 44zWCdglnHr --HG-- extra : rebase_source : fe07c557032fd33257eb701190becfaf85ab79d0
2018-01-17 14:20:35 +00:00
'registry',
]
Bug 1431090 - Prepare tools/fuzzing/ to be used with JS_STANDALONE. r=froydnj This patch adjusts tools/fuzzing/ in such a way that the relevant parts can be reused in the JS engine. Changes in detail include: * Various JS_STANDALONE checks to exclude parts that cannot be included in those builds. * Turn LibFuzzerRegistry and LibFuzzerRunner into generic FuzzerRegistry and FuzzerRunner classes and use them for AFL as well. Previously, AFL was piggy-backing on gtests which was kind of an ugly solution anyway (besides that it can't work in JS). Now more code like registry and harness is shared between the two and they follow almost the same call paths and entry points. AFL macros in FuzzingInterface have been rewritten accordingly. This also required name changes in various places. Furthermore, this unifies the way, the fuzzing target is selected, using the FUZZER environment variable rather than LIBFUZZER (using LIBFUZZER in browser builds will give you a deprecation warning because I know some people are using this already and need time to switch). Previously, AFL target had to be selected using GTEST_FILTER, so this is also much better now. * I had to split up FuzzingInterface* such that the STREAM parts are in a separate set of files FuzzingInterfaceStream* because they use nsStringStream which is not allowed to be included into the JS engine even in a full browser build (error: "Using XPCOM strings is limited to code linked into libxul."). I also had to pull FuzzingInterface.cpp (the RAW part only) into the header and make it static because otherwise, would have to make not only separate files but also separate libraries to statically link to the JS engine, which seemed overkill for a single small function. The streaming equivalent of the function is still in a cpp file. * LibFuzzerRegister functions are now unique by appending the module name to avoid redefinition errors. MozReview-Commit-ID: 44zWCdglnHr --HG-- extra : rebase_source : fe07c557032fd33257eb701190becfaf85ab79d0
2018-01-17 14:20:35 +00:00
if not CONFIG['JS_STANDALONE']:
DIRS += [
'common',
'faulty',
Bug 1431090 - Prepare tools/fuzzing/ to be used with JS_STANDALONE. r=froydnj This patch adjusts tools/fuzzing/ in such a way that the relevant parts can be reused in the JS engine. Changes in detail include: * Various JS_STANDALONE checks to exclude parts that cannot be included in those builds. * Turn LibFuzzerRegistry and LibFuzzerRunner into generic FuzzerRegistry and FuzzerRunner classes and use them for AFL as well. Previously, AFL was piggy-backing on gtests which was kind of an ugly solution anyway (besides that it can't work in JS). Now more code like registry and harness is shared between the two and they follow almost the same call paths and entry points. AFL macros in FuzzingInterface have been rewritten accordingly. This also required name changes in various places. Furthermore, this unifies the way, the fuzzing target is selected, using the FUZZER environment variable rather than LIBFUZZER (using LIBFUZZER in browser builds will give you a deprecation warning because I know some people are using this already and need time to switch). Previously, AFL target had to be selected using GTEST_FILTER, so this is also much better now. * I had to split up FuzzingInterface* such that the STREAM parts are in a separate set of files FuzzingInterfaceStream* because they use nsStringStream which is not allowed to be included into the JS engine even in a full browser build (error: "Using XPCOM strings is limited to code linked into libxul."). I also had to pull FuzzingInterface.cpp (the RAW part only) into the header and make it static because otherwise, would have to make not only separate files but also separate libraries to statically link to the JS engine, which seemed overkill for a single small function. The streaming equivalent of the function is still in a cpp file. * LibFuzzerRegister functions are now unique by appending the module name to avoid redefinition errors. MozReview-Commit-ID: 44zWCdglnHr --HG-- extra : rebase_source : fe07c557032fd33257eb701190becfaf85ab79d0
2018-01-17 14:20:35 +00:00
'messagemanager',
'shmem',
'ipc',
Bug 1431090 - Prepare tools/fuzzing/ to be used with JS_STANDALONE. r=froydnj This patch adjusts tools/fuzzing/ in such a way that the relevant parts can be reused in the JS engine. Changes in detail include: * Various JS_STANDALONE checks to exclude parts that cannot be included in those builds. * Turn LibFuzzerRegistry and LibFuzzerRunner into generic FuzzerRegistry and FuzzerRunner classes and use them for AFL as well. Previously, AFL was piggy-backing on gtests which was kind of an ugly solution anyway (besides that it can't work in JS). Now more code like registry and harness is shared between the two and they follow almost the same call paths and entry points. AFL macros in FuzzingInterface have been rewritten accordingly. This also required name changes in various places. Furthermore, this unifies the way, the fuzzing target is selected, using the FUZZER environment variable rather than LIBFUZZER (using LIBFUZZER in browser builds will give you a deprecation warning because I know some people are using this already and need time to switch). Previously, AFL target had to be selected using GTEST_FILTER, so this is also much better now. * I had to split up FuzzingInterface* such that the STREAM parts are in a separate set of files FuzzingInterfaceStream* because they use nsStringStream which is not allowed to be included into the JS engine even in a full browser build (error: "Using XPCOM strings is limited to code linked into libxul."). I also had to pull FuzzingInterface.cpp (the RAW part only) into the header and make it static because otherwise, would have to make not only separate files but also separate libraries to statically link to the JS engine, which seemed overkill for a single small function. The streaming equivalent of the function is still in a cpp file. * LibFuzzerRegister functions are now unique by appending the module name to avoid redefinition errors. MozReview-Commit-ID: 44zWCdglnHr --HG-- extra : rebase_source : fe07c557032fd33257eb701190becfaf85ab79d0
2018-01-17 14:20:35 +00:00
]
if not CONFIG['JS_STANDALONE'] and CONFIG['FUZZING_INTERFACES']:
DIRS += [
'rust',
]
if CONFIG['LIBFUZZER']:
DIRS += [
'libfuzzer',
]