7f58ced72e
While the overall goal of this commit is to change deoptimization entries into builtins, there are multiple related things happening: - Deoptimization entries, formerly stubs (i.e. Code objects generated at runtime, guaranteed to be immovable), have been converted into builtins. The major restriction is that we now need to preserve the kRootRegister, which was formerly used on most architectures to pass the deoptimization id. The solution differs based on platform. - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING. - Removed heap/ support for immovable Code generation. - Removed the DeserializerData class (no longer needed). - arm64: to preserve 4-byte deopt exits, introduced a new optimization in which the final jump to the deoptimization entry is generated once per Code object, and deopt exits can continue to emit a near-call. - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit sizes by 4/8, 5, and 5 bytes, respectively. On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes by using the same strategy as on arm64 (recalc deopt id from return address). Before: e300a002 movw r10, <id> e59fc024 ldr ip, [pc, <entry offset>] e12fff3c blx ip After: e59acb35 ldr ip, [r10, <entry offset>] e12fff3c blx ip On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases with CFI). Additionally, up to 4 builtin jumps are emitted per Code object (max 32 bytes added overhead per Code object). Before: 9401cdae bl <entry offset> After: # eager deoptimization entry jump. f95b1f50 ldr x16, [x26, <eager entry offset>] d61f0200 br x16 # lazy deoptimization entry jump. f95b2b50 ldr x16, [x26, <lazy entry offset>] d61f0200 br x16 # the deopt exit. 97fffffc bl <eager deoptimization entry jump offset> On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before: bb00000000 mov ebx,<id> e825f5372b call <entry> After: e8ea2256ba call <entry> On x64 the deopt exit size is reduced from 12 to 7 bytes. Before: 49c7c511000000 REX.W movq r13,<id> e8ea2f0700 call <entry> After: 41ff9560360000 call [r13+<entry offset>] Bug: v8:8661,v8:8768 Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70597} |
||
|---|---|---|
| .. | ||
| json | ||
| multi_return | ||
| parser | ||
| regexp | ||
| regexp_builtins | ||
| wasm | ||
| wasm_async | ||
| wasm_code | ||
| wasm_compile | ||
| BUILD.gn | ||
| DEPS | ||
| fuzzer-support.cc | ||
| fuzzer-support.h | ||
| fuzzer.cc | ||
| fuzzer.status | ||
| json.cc | ||
| multi-return.cc | ||
| parser.cc | ||
| README.md | ||
| regexp-builtins.cc | ||
| regexp.cc | ||
| testcfg.py | ||
| wasm_corpus.tar.gz.sha1 | ||
| wasm-async.cc | ||
| wasm-code.cc | ||
| wasm-compile.cc | ||
| wasm-fuzzer-common.cc | ||
| wasm-fuzzer-common.h | ||
| wasm.cc | ||
How to make a libFuzzer fuzzer in V8
This document describes how to make a new libFuzzer fuzzer for V8. A general introduction to libFuzzer can be found here. In short, libFuzzer is an in-process coverage-driven evolutionary fuzzer. libFuzzer serves you with a sequence of byte arrays that you can use to test your code. libFuzzer tries to generate this sequence of byte arrays in a way that maximizes test coverage.
Warning: By itself libFuzzer typically does not generate valid JavaScript code.
Changes to V8
tldr: Do the same as https://codereview.chromium.org/2280623002 to introduce a new fuzzer to V8.
This is a step by step guide on how to make a new fuzzer in V8. In the example
the fuzzer is called foo.
-
Copy one of the existing fuzzer implementations in test/fuzzer/, e.g.
cp wasm.cc foo.cc- Copying an existing fuzzer is a good idea to get all the required setup, e.g. setting up the isolate
-
Create a directory called
fooin test/fuzzer/ which contains at least one file- The file is used by the trybots to check whether the fuzzer actually compiles and runs
-
Copy the build rules of an existing fuzzer in BUILD.gn, e.g. the build rules for the wasm.cc fuzzer are
v8_source_set("wasm_fuzzer")andv8_fuzzer("wasm_fuzzer"). Note that the name has to be the name of the directory created in Step 2 +_fuzzerso that the scripts on the trybots work -
Now you can already compile the fuzzer, e.g. with
ninja -j 1000 -C out/x64.debug/v8_simple_foo_fuzzer- Use this binary to reproduce issues found by cluster fuzz, e.g.
out/x64.debug/v8_simple_foo_fuzzer testcase.foo
- Use this binary to reproduce issues found by cluster fuzz, e.g.
-
Copy the binary name and the test directory name in test/fuzzer/fuzzer.isolate
-
Add the fuzzer to the FuzzerTestSuite in test/fuzzer/testcfg.py
- This step is needed to run the fuzzer with the files created in Step 2 on the trybots
-
Commit the changes described above to the V8 repository
Changes to Chromium
tldr: Do the same as https://codereview.chromium.org/2344823002 to add the new fuzzer to cluster fuzz.
-
Copy the build rules of an existing fuzzer in testing/libfuzzer/fuzzers/BUILD.gn, e.g. the build rule for the wasm.cc fuzzer is
v8_wasm_fuzzer. There is no need to set adictionary, or aseed_corpus. See chromium-fuzzing-getting-started for more information. -
Compile the fuzzer in chromium (for different configurations see: https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md):
-
gn gen out/libfuzzer '--args=use_libfuzzer=true is_asan=true is_debug=false enable_nacl=false' -
ninja -j 1000 -C out/libfuzzer/ v8_foo_fuzzer
-
-
Run the fuzzer locally
mkdir /tmp/empty_corpus && out/libfuzzer/v8_foo_fuzzer /tmp/empty_corpus