2016-01-26 10:38:37 +00:00
|
|
|
# Copyright 2016 the V8 project authors. All rights reserved.
|
|
|
|
|
# Use of this source code is governed by a BSD-style license that can be
|
|
|
|
|
# found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
'variables': {
|
|
|
|
|
'files': [
|
2016-06-03 13:09:52 +00:00
|
|
|
'<(PRODUCT_DIR)/v8_simple_json_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_parser_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_regexp_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_fuzzer<(EXECUTABLE_SUFFIX)',
|
2017-06-13 14:41:54 +00:00
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_async_fuzzer<(EXECUTABLE_SUFFIX)',
|
2016-10-24 11:14:35 +00:00
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_call_fuzzer<(EXECUTABLE_SUFFIX)',
|
2016-08-29 13:55:41 +00:00
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_code_fuzzer<(EXECUTABLE_SUFFIX)',
|
[wasm] Syntax- and Type-aware Fuzzer
This is the beginning of a new fuzzer that generates
correct-by-construction Wasm modules. This should allow us to better
exercise the compiler and correctness aspects of fuzzing. It is based off
of ahaas' original Wasm fuzzer.
At the moment, it can generate expressions made up of most binops, and
also nested blocks with unconditional breaks. Future CLs will add
additional constructs, such as br_if, loops, memory access, etc.
The way the fuzzer works is that it starts with an array of arbitrary
data provided by libfuzzer. It uses the data to generate an expression.
Care is taken to make use of the entire string. Basically, the
generator has a bunch of grammar-like rules for how to construct an
expression of a given type. For example, an i32 can be made by adding
two other i32s, or by wrapping an i64. The process then continues
recursively until all the data is consumed.
We generate an expression from a slice of data as follows:
* If the slice is less than or equal to the size of the type (e.g. 4
bytes for i32), then it will emit the entire slice as a constant.
* Otherwise, it will consume the first 4 bytes of the slice and use
this to select which rule to apply. Each rule then consumes the
remainder of the slice in an appropriate way. For example:
* Unary ops use the remainder of the slice to generate the argument.
* Binary ops consume another four bytes and mod this with the length
of the remaining slice to split the slice into two parts. Each of
these subslices are then used to generate one of the arguments to
the binop.
* Blocks are basically like a unary op, but a stack of block types is
maintained to facilitate branches. For blocks that end in a break,
the first four bytes of a slice are used to select the break depth
and the stack determines what type of expression to generate.
The goal is that once this generator is complete, it will provide a one
to one mapping between binary strings and valid Wasm modules.
Review-Url: https://codereview.chromium.org/2658723006
Cr-Commit-Position: refs/heads/master@{#43289}
2017-02-17 17:06:29 +00:00
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_compile_fuzzer<(EXECUTABLE_SUFFIX)',
|
[wasm] Write fuzzers for single wasm sections.
This CL adds fuzzers for the wasm module sections 'types', 'names',
'globals', 'imports', 'function signatures', 'memory', and 'data', one
fuzzer per section. No fuzzers are added for the other sections because
either there already exists a fuzzer (e.g. wasm-code), or there exist
inter-section dependencies.
To avoid introducing a bunch executables which would make compilation
with make slow, I introduce a single executable
'v8_simple_wasm_section_fuzzer' which calls the fuzzers mentioned above.
This executable is run by the trybots and ensures that the fuzzers
actually compile. For debugging I introduce commandline parameters which
allow to execute the specific fuzzers from 'v8_simple_wasm_section_fuzzer'.
R=titzer@chromium.org, jochen@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2336603002
Cr-Commit-Position: refs/heads/master@{#39413}
2016-09-14 11:17:11 +00:00
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_data_section_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_function_sigs_section_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_globals_section_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_imports_section_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_memory_section_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_names_section_fuzzer<(EXECUTABLE_SUFFIX)',
|
|
|
|
|
'<(PRODUCT_DIR)/v8_simple_wasm_types_section_fuzzer<(EXECUTABLE_SUFFIX)',
|
2016-01-26 10:38:37 +00:00
|
|
|
'./fuzzer.status',
|
|
|
|
|
'./testcfg.py',
|
2016-02-02 11:28:47 +00:00
|
|
|
'./json/',
|
2016-01-26 10:38:37 +00:00
|
|
|
'./parser/',
|
2016-02-01 14:00:12 +00:00
|
|
|
'./regexp/',
|
2016-03-02 00:53:19 +00:00
|
|
|
'./wasm/',
|
2017-06-13 14:41:54 +00:00
|
|
|
'./wasm_async/',
|
2016-10-24 11:14:35 +00:00
|
|
|
'./wasm_call/',
|
2016-08-29 13:55:41 +00:00
|
|
|
'./wasm_code/',
|
[wasm] Syntax- and Type-aware Fuzzer
This is the beginning of a new fuzzer that generates
correct-by-construction Wasm modules. This should allow us to better
exercise the compiler and correctness aspects of fuzzing. It is based off
of ahaas' original Wasm fuzzer.
At the moment, it can generate expressions made up of most binops, and
also nested blocks with unconditional breaks. Future CLs will add
additional constructs, such as br_if, loops, memory access, etc.
The way the fuzzer works is that it starts with an array of arbitrary
data provided by libfuzzer. It uses the data to generate an expression.
Care is taken to make use of the entire string. Basically, the
generator has a bunch of grammar-like rules for how to construct an
expression of a given type. For example, an i32 can be made by adding
two other i32s, or by wrapping an i64. The process then continues
recursively until all the data is consumed.
We generate an expression from a slice of data as follows:
* If the slice is less than or equal to the size of the type (e.g. 4
bytes for i32), then it will emit the entire slice as a constant.
* Otherwise, it will consume the first 4 bytes of the slice and use
this to select which rule to apply. Each rule then consumes the
remainder of the slice in an appropriate way. For example:
* Unary ops use the remainder of the slice to generate the argument.
* Binary ops consume another four bytes and mod this with the length
of the remaining slice to split the slice into two parts. Each of
these subslices are then used to generate one of the arguments to
the binop.
* Blocks are basically like a unary op, but a stack of block types is
maintained to facilitate branches. For blocks that end in a break,
the first four bytes of a slice are used to select the break depth
and the stack determines what type of expression to generate.
The goal is that once this generator is complete, it will provide a one
to one mapping between binary strings and valid Wasm modules.
Review-Url: https://codereview.chromium.org/2658723006
Cr-Commit-Position: refs/heads/master@{#43289}
2017-02-17 17:06:29 +00:00
|
|
|
'./wasm_compile/',
|
[wasm] Write fuzzers for single wasm sections.
This CL adds fuzzers for the wasm module sections 'types', 'names',
'globals', 'imports', 'function signatures', 'memory', and 'data', one
fuzzer per section. No fuzzers are added for the other sections because
either there already exists a fuzzer (e.g. wasm-code), or there exist
inter-section dependencies.
To avoid introducing a bunch executables which would make compilation
with make slow, I introduce a single executable
'v8_simple_wasm_section_fuzzer' which calls the fuzzers mentioned above.
This executable is run by the trybots and ensures that the fuzzers
actually compile. For debugging I introduce commandline parameters which
allow to execute the specific fuzzers from 'v8_simple_wasm_section_fuzzer'.
R=titzer@chromium.org, jochen@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2336603002
Cr-Commit-Position: refs/heads/master@{#39413}
2016-09-14 11:17:11 +00:00
|
|
|
'./wasm_data_section/',
|
|
|
|
|
'./wasm_function_sigs_section/',
|
|
|
|
|
'./wasm_globals_section/',
|
|
|
|
|
'./wasm_imports_section/',
|
|
|
|
|
'./wasm_memory_section/',
|
|
|
|
|
'./wasm_names_section/',
|
|
|
|
|
'./wasm_types_section/',
|
2016-01-26 10:38:37 +00:00
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
'includes': [
|
|
|
|
|
'../../src/base.isolate',
|
|
|
|
|
'../../tools/testrunner/testrunner.isolate',
|
|
|
|
|
],
|
|
|
|
|
}
|
