This CL makes a fuzzer out of the cctest
test-multiple-return/ReturnMultipleRandom. The fuzzer creates a
CallDescriptor with input parameters and returns, and a function which
maps input parameters to returns. The fuzzer then calls this function
with a wrapper which checks that the correct mapping happened.
R=clemensh@chromium.org
Change-Id: Ib89c4063638baae69540a44486d7b2e9d13f8c1f
Reviewed-on: https://chromium-review.googlesource.com/859768
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50532}
The wasm-async fuzzer uses the bytes provided by the fuzzer engine
directly as wasm module bytes, compiles them with async compilation, and
then tries to execute the "main" function of the module. This "main"
can have an infinite loop which causes a timeout in the fuzzer. With
this CL the "main" function is first executed with the interpreter. If
the execution in the interpreter finishes within 16k steps, which means
that there is no infinite loop, also the compiled code is executed.
I added the raw fuzzer input as a test case because in this case I
really want to test the fuzzer and not V8.
R=clemensh@chromium.org
Bug: chromium:761784
Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
Reviewed-on: https://chromium-review.googlesource.com/651046
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47874}
The fuzzer has already been removed from chromium. In addition I removed
code which was only used by this fuzzer.
BUG=chromium:734550
R=clemensh@chromium.orgCC=mstarzinger@chromium.org
Change-Id: I2ff4614e4d64131412ead759318e5c38e38f5d3d
Reviewed-on: https://chromium-review.googlesource.com/542816
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46078}
The new fuzzer takes the fuzzer input as module bytes and compiles them
with WebAssembly asynchronous compilation.
R=mtrofin@chromium.org
Change-Id: I9740edec68e26c04d011d85c68521e340be13c4c
Reviewed-on: https://chromium-review.googlesource.com/506156
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45912}
With this CL we share code among the wasm fuzzers which construct a
module and run it in the interpreter and as compiled code.The fuzzers
themselves only contain the code now which creates the module and the
parameters.
BUG=v8:6325
R=eholk@chromium.org
Change-Id: I1c2d8b013531c86cb27837f1b8ec89d2688c536b
Reviewed-on: https://chromium-review.googlesource.com/490048
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45156}
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}
In component build, fuzzer did not link with icu libraries, causing
errors. By adding icu libraries to dependencies fuzzer links correctly.
BUG=
TEST=fuzzer/*
Review-Url: https://codereview.chromium.org/2510063002
Cr-Commit-Position: refs/heads/master@{#41098}
Depending on the inputs the fuzzer creates multiple functions. These
functions can have signatures with an int32 return value and up to three
parameters of type int32, int64, float32, or float64.
R=titzer@chromium.org, clemensh@chromium.org
Review-Url: https://codereview.chromium.org/2447643002
Cr-Commit-Position: refs/heads/master@{#40530}
Reason for revert:
Speculative revert due to very strange-looking win/dbg failures
which reference SignedDivisionByConstant:
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736
Original issue's description:
> Reland "Turn libbase into a component"
>
> Original issue's description:
> > Turn libbase into a component
> >
> > This is a precondition for turning libplatform into a component
> >
> > BUG=v8:5412
> > R=jgruber@chromium.org,machenbach@chromium.org
> > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_
> dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
> >
> > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104
> > Cr-Commit-Position: refs/heads/master@{#39950}
>
> BUG=v8:5412
> TBR=jgruber@chromium.org,machenbach@chromium.org
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
>
> Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb
> Cr-Commit-Position: refs/heads/master@{#39969}
TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5412
Review-Url: https://codereview.chromium.org/2396933002
Cr-Commit-Position: refs/heads/master@{#40009}
Original issue's description:
> Turn libbase into a component
>
> This is a precondition for turning libplatform into a component
>
> BUG=v8:5412
> R=jgruber@chromium.org,machenbach@chromium.org
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_
dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
>
> Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104
> Cr-Commit-Position: refs/heads/master@{#39950}
BUG=v8:5412
TBR=jgruber@chromium.org,machenbach@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
Review-Url: https://codereview.chromium.org/2395553002
Cr-Commit-Position: refs/heads/master@{#39969}
Reason for revert:
Main suspect for roll block:
https://codereview.chromium.org/2387403002/
Original issue's description:
> Turn libbase into a component
>
> This is a precondition for turning libplatform into a component
>
> BUG=v8:5412
> R=jgruber@chromium.org,machenbach@chromium.org
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
>
> Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104
> Cr-Commit-Position: refs/heads/master@{#39950}
TBR=jgruber@chromium.org,jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5412
Review-Url: https://codereview.chromium.org/2393603002
Cr-Commit-Position: refs/heads/master@{#39960}
This is a precondition for turning libplatform into a component
BUG=v8:5412
R=jgruber@chromium.org,machenbach@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
Review-Url: https://codereview.chromium.org/2381273002
Cr-Commit-Position: refs/heads/master@{#39950}
V8 is collecting a growing amount of fuzzers, all of which take substantial
space on the bots and in chromium build archives. This CL improves that
situation by allowing component (shared library) builds for almost all fuzzers.
The parser fuzzer is handled as an exception since it would require exporting a
large number of additional functions.
A component build results in about a 50-100x improvement in file size for each
fuzzer (~50M-100M to around 1.1M).
BUG=chromium:648864
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
Review-Url: https://codereview.chromium.org/2360983002
Cr-Commit-Position: refs/heads/master@{#39709}
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}
The wasm-module-runner is used both in cctests and in fuzzers. As
discussed offline, it is weird to include cctest header files in
fuzzers, so I introduce a new test/common directory which contains the
common files.
R=titzer@chromium.org, jochen@chromium.org
Review-Url: https://codereview.chromium.org/2335193002
Cr-Commit-Position: refs/heads/master@{#39411}
With this CL the wasm-code-fuzzer first decodes and interprets the test
case generated by the fuzzer. It then compiles the test case, but only
executes the compiled instance if the interpretation of the test case
was successful. If the compiled instance is executed, then the result of
the execution is compared with the result of the interpretation.
Additionally this CL refactors the CompileAndRunWasmModule function in
wasm-module.cc to resuse code in the call to the interpreter.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2321443002
Cr-Commit-Position: refs/heads/master@{#39351}
This adds the v8-side fuzzer executables for smoke testing.
This also renames the old gyp targets to stay consistent
with chromium.
Naming convention for type X after the rename:
library: X_fuzzer (gn), X_fuzzer_lib (gyp)
executable v8: v8_simple_X_fuzzer
executable chromium: v8_X_fuzzer
BUG=chromium:474921
Review-Url: https://codereview.chromium.org/2032363002
Cr-Commit-Position: refs/heads/master@{#36713}
This prepares for pulling chromium's build as dependency for
gn. After this, the files in build and gypfiles need to stay
in sync until chromium is updated.
BUG=chromium:474921
LOG=n
Review-Url: https://codereview.chromium.org/1848553003
Cr-Commit-Position: refs/heads/master@{#35898}
This will allow to pull in gyp as a deps to the same location
as chromium (tools/gyp not build/gyp), needed for gn switch.
This is the first step of a 3-way move.
1) Copy v8.gyp in v8
2) Update references in embedders (follow up)
3) Remove old v8.gyp (follow up)
BUG=chromium:474921
LOG=n
NOTRY=true
Review URL: https://codereview.chromium.org/1920793002
Cr-Commit-Position: refs/heads/master@{#35760}
