The WebAssembly spec is not fully deterministic: the sign bit of NaN
can be arbitrary. This sign bit can be observed by several WebAssembly
opcodes. In the testcase the sign bit of NaN makes the difference
between terminating code and an infinite loop.
In the libfuzzer fuzzer we have to prevent infinite loops ourselves.
At the moment we do this by only execute generated code of WebAssembly
modules for which the interpretation of the code ends in a limited
number of steps. With the non-determinism described above we cannot
guarantee the absence of infinite loops with this method. Therefore
we stop now to execute generated code of WebAssembly modules for which
we observe possible non-determinism in the interpreter.
R=clemensh@chromium.org
Bug: chromium:863829
Change-Id: I461d67df87d672bed25d6c915ba7ea5134cb5890
Reviewed-on: https://chromium-review.googlesource.com/1141945
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54541}
Currently the fuzzer only tests Turbofan and Liftoff in isolation. In
order to test that both tiers use the same ABI, it should also test
calls from one tier to the other.
This CL introduces a new flag which controls which function will be
compiled by which tier, and uses that in the fuzzer.
R=ahaas@chromium.org
Bug: chromium:862931, v8:6600
Change-Id: I450b906700972cfdb496b1734faed9f8208d652f
Reviewed-on: https://chromium-review.googlesource.com/1134775
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54409}
Instead of passing {uint8_t*, size_t} pairs as arguments, pass
{Vector<uint8_t>}. This is less error prone and {Vector} provides some
helpful methods.
R=ahaas@chromium.org
Bug: v8:7754
Change-Id: I7469054774618e0bd5c9d38501759b1b2c51d104
Reviewed-on: https://chromium-review.googlesource.com/1134773
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54406}
In the WebAssembly fuzzers we detect infinite loops with the
interpreter: if the interpreter does not finish after a finite number
of steps, we do not execute the compiled code. However, we cannot
redirect the start function to the interpreter in the fuzzer, and
therefore we cannot detect infinite loops in the start function. With
this CL we avoid the problem completely by not instantiating a module
in the fuzzer which has a start function. Note that the module still
gets compiled.
R=clemensh@chromium.org
Bug: chromium:858914
Change-Id: Icbbe9a003544918d5267cdd1d9405b21bb681133
Reviewed-on: https://chromium-review.googlesource.com/1126766
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54246}
The current output of release builds is not very helpful, as it does
not contain the line number, nor the values of {expect_exception} or
{i_isolate->has_pending_exception()}.
R=ahaas@chromium.org
Bug: chromium:854011
Change-Id: I0bc1b8be6151d5420310eb67b2ebd0dc866fc9a6
Reviewed-on: https://chromium-review.googlesource.com/1122869
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54164}
Before flipping the flag, some tests need to be adapted. This CL
prepares these tests, such that the flag flip CL really just flips a
flag.
R=titzer@chromium.org, hablich@chromium.org
Bug: v8:6600, chromium:787421
Change-Id: I8030df69cda5f3fb81354350a37f65c0d1c669bd
Reviewed-on: https://chromium-review.googlesource.com/1110363
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53959}
Other fuzzers already have this ability. This CL adds it to the fuzzer.
The input has to be valid bytes, otherwise we cannot generate the text
representation.
R=titzer@chromium.orgCC=gdeepti@chromium.org
Change-Id: If1ba8accc707bee3b042e93f4201949f0233c90e
Reviewed-on: https://chromium-review.googlesource.com/1109794
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53926}
We currently store the {WasmModule} (generated during decoding) in a
unique_ptr and pass ownership to the {WasmModuleObject} after
compilation.
I plan to move the {Managed<NativeModule>} from {WasmCompiledModule} to
{WasmModuleObject}, which will force us to create the
{WasmModuleObject} *before* compilation, so that the {CompilationState}
is available during compilation.
This CL prepares that refactoring by storing the {WasmModule} in a
{shared_ptr} in the {AsyncCompileJob}. Note that it will eventually be
stored in a {shared_ptr} in the {Managed} anyway.
R=titzer@chromium.org
Change-Id: Iac5e3c1067af2801e938f77a455a68807801526a
Reviewed-on: https://chromium-review.googlesource.com/1104117
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53801}
This is a reland of 0909dbe3d6.
Added missing V8_EXPORT_PRIVATE to AndroidLogStream.
TBR=mstarzinger@chromium.org
Original change's description:
> Introduce StdoutStream which prints to Android log or stdout
>
> The often used construct {OFStream(stdout)} does not work on Android.
> This CL introduces an {StdoutStream} which behaves exactly like
> {OFStream(stdout)} on non-android platforms, and redirects to the
> Android log on appropriate systems and configurations.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:7820
> Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
> Reviewed-on: https://chromium-review.googlesource.com/1088911
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53692}
Bug: v8:7820
Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
Reviewed-on: https://chromium-review.googlesource.com/1100636
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53733}
This reverts commit 0909dbe3d6.
Reason for revert: Blocks roll:
https://chromium-review.googlesource.com/c/chromium/src/+/1099143
Original change's description:
> Introduce StdoutStream which prints to Android log or stdout
>
> The often used construct {OFStream(stdout)} does not work on Android.
> This CL introduces an {StdoutStream} which behaves exactly like
> {OFStream(stdout)} on non-android platforms, and redirects to the
> Android log on appropriate systems and configurations.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:7820
> Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
> Reviewed-on: https://chromium-review.googlesource.com/1088911
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53692}
TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org
Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7820
Reviewed-on: https://chromium-review.googlesource.com/1100635
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53725}
The often used construct {OFStream(stdout)} does not work on Android.
This CL introduces an {StdoutStream} which behaves exactly like
{OFStream(stdout)} on non-android platforms, and redirects to the
Android log on appropriate systems and configurations.
R=mstarzinger@chromium.org
Bug: v8:7820
Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
Reviewed-on: https://chromium-review.googlesource.com/1088911
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53692}
This CL splits the definition of ValueType and its helper functions
into its own header file.
R=clemensh@chromium.org
Bug: v8:7570
Change-Id: I3aa776edb45839d7d38836e131df45732c685310
Reviewed-on: https://chromium-review.googlesource.com/1021810
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52758}
Mostly cosmetic changes. The biggest change is to encode block result
types using symbolic names instead of hex numbers.
R=ahaas@chromium.org
Change-Id: Ic0e6eccf687338e68508094168ddd70734cef301
Reviewed-on: https://chromium-review.googlesource.com/973527
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52138}
This is a further step to separate the implementation of the JavaScript
API from the internals of the WASM implementation. Now, wasm-js.cc
only needs to interact with the WASM engine and is (almost) independent
of module-decoder.h and module-compiler.h.
Also, move SyncCompileAndInstantiate() into wasm-module-runner.cc.
Bug: v8:7316
R=clemensh@chromium.org, mstarzinger@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I7765af54ac16f53a5ff88c17a22c5d36bacaf926
Reviewed-on: https://chromium-review.googlesource.com/870871
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50679}
This is the first in a series of CLs that will separate the JS API
from the implementation of WebAssembly by bottlenecking interactions
through the WasmEngine. In the long run, the JS API and much of V8
should rely only on the WasmEngine interface, which will represent
the "public interface" for embedding WebAssembly.
Next: hide compilation-related methods behind WasmEngine.
Bug: v8:7316
Change-Id: I93404f0dc8a201ae99d30b4c1ca34606e3dddbca
Reviewed-on: https://chromium-review.googlesource.com/868590
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50660}
The tests generated by --wasm-fuzzer-gen-test did not encode the locals
of functions yet. This CL fixes that.
A bit of care has to be taken to ensure that the locals are generated
in exactly the same order as in the module generated by the fuzzer.
This requires calling {addLocals} several times.
R=ahaas@chromium.org
Change-Id: I95237b0baef0731b6c164fddc8f12fa6f478e220
Reviewed-on: https://chromium-review.googlesource.com/848832
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50402}
Test case generation produced unusable output if the module contains
more than one function. Also, it was unnecessarily scattered around
several places in the code.
This CL consolidates test case generation in one method in the fuzzer,
and supports multiple functions with different signatures.
R=ahaas@chromium.org
Change-Id: I8bea71b0d69bb69d8bbe50002c6c7616a0a1941b
Reviewed-on: https://chromium-review.googlesource.com/847515
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50400}
This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.
Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.
Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.
BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
Pending exceptions were not cleared when the TurboFan result was not
compared to the Interpreter result, which happens when the result may be
affected by potential nondeterminism. With this CL we always clear
pending exceptions.
R=clemensh@chromium.org
Bug: chromium:782267
Change-Id: Ibe9b33c94810cccb6282c6c8dc49748fb79b07e4
Reviewed-on: https://chromium-review.googlesource.com/758272
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49265}
The Wasm AST-based fuzzer is supposed to create valid modules by
construction. This change adds a CHECK to enforce this property.
Additionally, this change exposed several cases where we were not generating
valid modules before:
* Block types did not match up correctly
* Memory operations could have invalid alignments
* Storing an i64 could generate an i32 argument incorrectly.
This CL includes fixes for these issues as well.
Bug:
Change-Id: I1aef5532bc880367ec46dc6e79b2d4dbacf2f84b
Reviewed-on: https://chromium-review.googlesource.com/757129
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49241}
For each single bug, the fuzzer might find many very similar inputs
which trigger this bug. All of them are reported as individual bugs
currently, which means lots of noise in bug reports and increased
workload for the clusterfuzz sheriffs.
After this change, all bugs of the same category ("compiles !=
validates", "interpreter != liftoff", ...) will be grouped together.
This requires us to fix them soon after reporting, as they will hide
all other bugs of the same category.
R=ahaas@chromium.orgCC=mmoroz@chromium.org
Change-Id: Ie203eed0c7681e3450df977b10c0d9dbbc402d34
Reviewed-on: https://chromium-review.googlesource.com/758438
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49231}
Each valid memory module generated by one of the wasm fuzzers will now
also be executed in Liftoff, and the result of the execution will be
compared against the interpreted result.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I6a437faae4230ce4dfc7924dd1418da20ea92356
Reviewed-on: https://chromium-review.googlesource.com/753328
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49154}
Note that this also makes it possible to move several classes
into the module-compiler.cc file and inline their implementations.
This also allows removing several uses of wasm-module.h from
other places in V8 that include wasm-objects.h.
R=yangguo@chromium.org,clemensh@chromium.org,ahaas@chromium.org
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I303ee2bb49dc53c951d377a1b65699c1e0e91da7
Reviewed-on: https://chromium-review.googlesource.com/687494
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48204}
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}
This violates the style guide, and causes problems for jumbo builds.
R=ahaas@chromium.orgCC=mostynb@opera.com
Bug: chromium:746958
Change-Id: Ic583c41b94bfd9ecdb31a9ccadb2e842861fe7f4
Reviewed-on: https://chromium-review.googlesource.com/647710
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47774}
To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method ("unity builds") to both
compile faster and create a poor man's "full program optimization".
We are only interested in compile times.
Background:
https://chromium.googlesource.com/chromium/src/+/master/docs/jumbo.md
Note that jumbo builds are not enabled by default. To try this out,
add use_jumbo_build=true to your GN args.
BUG=chromium:746958
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ieb9fdccb6c135e9806dbed91c09a29aa8b8bee11
Reviewed-on: https://chromium-review.googlesource.com/579090
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47239}
This allows to reuse the class e.g. in the baseline compiler.
R=titzer@chromium.org
Change-Id: I7251af16e8c74f267834a9cefb676edf3c9f3a07
Reviewed-on: https://chromium-review.googlesource.com/570020
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46735}
After compiling a function, check that validation produces the same
success/error result.
R=ahaas@chromium.org
Change-Id: I617881e125dccff485f5572557b19709de488d55
Reviewed-on: https://chromium-review.googlesource.com/565722
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46561}
If the fuzzer input cannot be executed in the interpreter within a step
limit, then the interpreter does not calculate the result but instead
finishes with a RangeError. The problem with the input of the bug report
was that the interpreter finished with that RangeError, but the
execution of the compiled code still returned a result, which was
naturally not a RangeError and therefore caused the result check to fail.
With this CL the compiled code is not even executed when there is a
RangeError after the execution in the interpreter. Thereby we also
avoid executing an infinite loop.
BUG=chromium:734435
R=clemensh@chromium.org
Change-Id: If9d0fb9e14e84f06d6f11d22f882363d56c1c20b
Reviewed-on: https://chromium-review.googlesource.com/544838
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46140}
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}
This CL removes unnecessary code duplication in the fuzzer code. Instead
of having special testing functions to compile and instantiate a
WebAssembly module, we now just call SyncCompile and SyncInstantiate.
This also fixed a problem when the fuzzer generated a GrowMemory
instruction.
BUG=v8:6474
R=clemensh@chromium.org
Change-Id: I5f2f23349b5866ea67be20a0826271791e1a013e
Reviewed-on: https://chromium-review.googlesource.com/529210
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45851}
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}
