- 27 Oct, 2017 1 commit
-
-
Michael Achenbach authored
The status-file flags and the flags from the test case's source code must always overwrite extra flags set by bots. Bug: v8:6924 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I0e2aabb69da7cfb8ba6c1c79bd3851462071a6ac Reviewed-on: https://chromium-review.googlesource.com/732656 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#49001}
-
- 05 Oct, 2017 1 commit
-
-
Max Moroz authored
R=ahaas@chromium.org, ochang@chromium.org Bug: Chromium:539572 Change-Id: I9e94a03c9173d0a17cb1a18dc8740972ff794368 Reviewed-on: https://chromium-review.googlesource.com/701601 Commit-Queue: Max Moroz <mmoroz@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48317}
-
- 28 Sep, 2017 1 commit
-
-
Ben L. Titzer authored
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/687494Reviewed-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}
-
- 11 Sep, 2017 2 commits
-
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: If0554f01068fb76228e85cfe120630eda86de41d Reviewed-on: https://chromium-review.googlesource.com/659997Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47945}
-
Clemens Hammacher authored
Cleanup before enabling the presubmit check: https://chromium-review.googlesource.com/c/v8/v8/+/657104 Bug: v8:6811 R=ahaas@chromium.org CC=mstarzinger@chromium.org Change-Id: Ifbf9210464b46dfdb5e04fbedc41d30e11536f74 Reviewed-on: https://chromium-review.googlesource.com/657422Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47943}
-
- 07 Sep, 2017 1 commit
-
-
Andreas Haas authored
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}
-
- 04 Sep, 2017 1 commit
-
-
Clemens Hammacher authored
After this CL, we will enable cpplint checks for this directory on presubmit: https://chromium-review.googlesource.com/647807 R=mstarzinger@chromium.org Change-Id: Ie85e876a7245cc5c8d5bf9348c8841040a8edbe9 Reviewed-on: https://chromium-review.googlesource.com/647552Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47791}
-
- 01 Sep, 2017 1 commit
-
-
Clemens Hammacher authored
This violates the style guide, and causes problems for jumbo builds. R=ahaas@chromium.org CC=mostynb@opera.com Bug: chromium:746958 Change-Id: Ic583c41b94bfd9ecdb31a9ccadb2e842861fe7f4 Reviewed-on: https://chromium-review.googlesource.com/647710Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47774}
-
- 29 Aug, 2017 2 commits
-
-
jgruber authored
Crashes are still happening despite tentative fixes, but unfortunately without a local repro. This adds a couple of additional checks to help flush out the root cause. TBR=yangguo@chromium.org Bug: chromium:754422 Change-Id: Ib3c8a2e0271fc724a4351ce6aec8298cf520a20a Reviewed-on: https://chromium-review.googlesource.com/640691Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47684}
-
Michael Starzinger authored
This adds support to specify the maximum memory size when building a WebAssembly module. Default is not maximum, one can be explicitly set. It is mainly used by the WebAssembly fuzzers to prevent OOMs. R=ahaas@chromium.org BUG=chromium:759973 Change-Id: Ibf5fa63a7e36e5f3b65ced528c73a65355d5632f Reviewed-on: https://chromium-review.googlesource.com/640386Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47676}
-
- 28 Aug, 2017 1 commit
-
-
jgruber authored
TryCatch only clears the pending exception if it has been propagated through OptionalRescheduleException. This is another tentative fix for https://crbug.com/754422. Bug: chromium:754422 Change-Id: Ifbbeed8ef44131a0a010ac6bde3adbbf9fb4c4af Reviewed-on: https://chromium-review.googlesource.com/637305Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47634}
-
- 25 Aug, 2017 1 commit
-
-
jgruber authored
Tentative fix for the CF crashes in https://crbug.com/754422. Bug: chromium:754422 Change-Id: I0dcb6b8860cb0bf20b3566ffba08e6772398ee65 Reviewed-on: https://chromium-review.googlesource.com/632176Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47591}
-
- 09 Aug, 2017 1 commit
-
-
Mostyn Bramley-Moore authored
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}
-
- 03 Aug, 2017 1 commit
-
-
Andreas Haas authored
The ScheduledErrorThrower is also needed in the wasm-async fuzzer so I moved the implementation from wasm-js.cc to wasm-api.[h|cc]. R=clemensh@chromium.org Bug: chromium:749838 Change-Id: I49d7438d1ec0281285ce0c64ba462c22001be08e Reviewed-on: https://chromium-review.googlesource.com/591447 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47112}
-
- 18 Jul, 2017 1 commit
-
-
Clemens Hammacher authored
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/570020Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46735}
-
- 11 Jul, 2017 1 commit
-
-
Clemens Hammacher authored
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/565722Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46561}
-
- 22 Jun, 2017 1 commit
-
-
Andreas Haas authored
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}
-
- 21 Jun, 2017 1 commit
-
-
Andreas Haas authored
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.org CC=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}
-
- 13 Jun, 2017 1 commit
-
-
Andreas Haas authored
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}
-
- 12 Jun, 2017 3 commits
-
-
Andreas Haas authored
The EnableFlagScope is useful also for non-boolean flags. With the template we can use if for example in the wasm fuzzers to reduce the maximum memory size of a wasm module. In addition I put the EnableFlagScope into the v8::internal namespace, and I fixed a small typo. BUG=v8:6474 R=clemensh@chromium.org Change-Id: Iae5d5c058c334cd0f9e09d20adfd229fc2d6c585 Reviewed-on: https://chromium-review.googlesource.com/531005 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45862}
-
Clemens Hammacher authored
This is a testing-only function, which is semantically equivalent to a SyncCompile followed by SyncInstantiate. We add a new SyncCompileAndInstantiate function to do those two steps in one go, and use this method instead. For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is introduced. This is part of our effort to reduce the number of special paths for testing. It is connected with https://chromium-review.googlesource.com/529210, but should not conflict with it. After landing both CLs, we can later also get rid of InstantiateModuleForTesting. R=ahaas@chromium.org, mtrofin@chromium.org BUG=v8:6474 Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc Reviewed-on: https://chromium-review.googlesource.com/529844Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45852}
-
Andreas Haas authored
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}
-
- 09 Jun, 2017 1 commit
-
-
Andreas Haas authored
The wasm-code fuzzer used different parameters for the interpreter and the generated code due to a typo. This typo is fixed by this CL. R=clemensh@chromium.org Change-Id: Ia9c72b83e7722e0a8b3fe6efb3f4b32ca5c937ab Reviewed-on: https://chromium-review.googlesource.com/527447Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#45812}
-
- 31 May, 2017 1 commit
-
-
Andreas Haas authored
In https://chromium-review.googlesource.com/c/505614/ I added code to the test runner which deletes the old corpus of the wasm fuzzer. It's time now to remove this code again. R=machenbach@chromium.org Change-Id: Ic3b8f7a1f6d725f0bf070b404a75ac37551a07c0 Reviewed-on: https://chromium-review.googlesource.com/519405Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#45641}
-
- 19 May, 2017 1 commit
-
-
Andreas Haas authored
In a recent CL I moved the corpus of the wasm fuzzer and of the wasm-asmjs fuzzer to a different directory (wasm_corpus and wasm_asmjs_corpus) so that the corpus is not executed on the try-bots. With this CL I remove the old corpus from the .gitignore file. In addition I removed the hooks for wasm_corpus and wasm_asmjs_corpus from the V8 DEPS file, because in a V8 checkout they are not used anyway. I also added code to the test runner to delete all *.wasm files from the directories test/fuzzer/wasm and test/fuzzer/wasm_asmjs. This code should be removed in a week, but it will help my coworkers to cleanup their V8 checkout. R=bradnelson@chromium.org CC=machenbach@chromium.org Change-Id: I9fdf9d77b71b133f84f7e744763d65fdf127d624 Reviewed-on: https://chromium-review.googlesource.com/505614 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45417}
-
- 17 May, 2017 1 commit
-
-
mmoroz authored
Non-printable characters do not make sense. Inputs with non balanced brackets are mostly useless as well. This validation function makes the fuzzer 15-20x faster. Also use -only_ascii=1 option of libFuzzer: https://codereview.chromium.org/2875933003 BUG=chromium:584819 Review-Url: https://codereview.chromium.org/2881583002 Cr-Commit-Position: refs/heads/master@{#45367}
-
- 12 May, 2017 1 commit
-
-
Michael Starzinger authored
This makes sure that the order of exports as they appear in asm.js modules is maintained globally (not just per function) while being translated to a WASM module. R=clemensh@chromium.org TEST=mjsunit/asm/asm-validation BUG=chromium:720586 Change-Id: I8b26d717ae2f88467d41670bced901f196c7b3fc Reviewed-on: https://chromium-review.googlesource.com/503708 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45277}
-
- 08 May, 2017 1 commit
-
-
Andreas Haas authored
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}
-
- 02 May, 2017 1 commit
-
-
Michael Starzinger authored
This ensures exceptions thrown during parsing are properly propagated into the surrounding {v8::TryCatch} block. Otherwise running more than one test input in the same Isolate can fail due to pending exceptions. R=jochen@chromium.org BUG=chromium:715037 Change-Id: Iaa5735515dc097d8cb12dcf8672451f3c9503440 Reviewed-on: https://chromium-review.googlesource.com/490047 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#45019}
-
- 28 Apr, 2017 1 commit
-
-
Andreas Haas authored
The current test/fuzzer/wasm directory is used for two things: 1) as the corpus directory for clusterfuzz 2) to test in v8 that the fuzzer runs correctly. With the newly added files from the wasm spec tests this directory grew quite big and adds unnecessary load on the trybots. Therefore I want to do the following steps: 1) In this CL for V8: create a new directory for the clusterfuzz corpus 2) In chromium: use the new corpus directory 3) In v8: clean up the old directory to use it on the trybots. R=bradnelson@chromium.org CC=mmoroz@chromium.org Change-Id: If690022558bb5780edf5a3649fb9745ef9c7407a Reviewed-on: https://chromium-review.googlesource.com/490367 Commit-Queue: Brad Nelson <bradnelson@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#44991}
-
- 27 Apr, 2017 1 commit
-
-
Andreas Haas authored
I moved the wasm update scripts from tools/ to tools/wasm. In addition I cleaned up the scripts a bit. R=machenbach@chromium.org Change-Id: I545dd556712e272e6509b78e343e9063346abe56 Reviewed-on: https://chromium-review.googlesource.com/488601Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44940}
-
- 25 Apr, 2017 2 commits
-
-
Clemens Hammacher authored
Instead of using the WASM_I32V_* macros (and other) from wasm-macro-gen.h, use the appropriate methods to encode LEB integers. This also saves some spaces for the wasm bytecode generated from asm.js. Specifically, this CL 1) renames EmitVarInt to EmitI32V and EmitVarUint to EmitU32V (on WasmFunctionBuilder). 2) introduces more methods on the WasmFunctionBuilder to emit i64v, u64v, f32, and f64 values. 3) uses the ZoneBuffer instead of a plain ZoneVector<char> in the WasmFunctionBuilder to build the body of the function. 4) introduces more helper functions on the ZoneBuffer to encode i64v, u64v, f32 and f64 values. R=ahaas@chromium.org Change-Id: Ifa59a6a67380ecf9a3823c382daf00855f5bc61e Reviewed-on: https://chromium-review.googlesource.com/486803Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#44842}
-
Andreas Haas authored
I think the WebAssembly format changed since the last time we updated the corpus. R=bradnelson@chromium.org Change-Id: Ic4e24bade8cffbd43025d0961b805757a5e6f4d6 Reviewed-on: https://chromium-review.googlesource.com/485801Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44832}
-
- 07 Apr, 2017 1 commit
-
-
Clemens Hammacher authored
The format of the name section changed recently. It now contains subsections of different type (currently for function names or local variable names). This CL changes our internal wasm module builders (in JS and C++) to emit this new format, and changes the decoder to understand it. We currently only parse the function name section, and ignore names of local variables. I will later extend this to parse local variable names when needed for debugging. R=ahaas@chromium.org, rossberg@chromium.org BUG=v8:6222 Change-Id: I2627160c25c9209a3f09abe0b88941ec48b24434 Reviewed-on: https://chromium-review.googlesource.com/470247 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Rossberg <rossberg@chromium.org> Cr-Commit-Position: refs/heads/master@{#44492}
-
- 04 Apr, 2017 1 commit
-
-
Franziska Hinkelmann authored
Getting elements, querying length or copying elements are now const functions. Drive-by fix: Noticed a few more getters that should be const. Add a comment to ArrayList functions that are static functions. BUG= Change-Id: I5de1aed97510dea4e47cb974b3259da51ae663af Reviewed-on: https://chromium-review.googlesource.com/467249Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#44372}
-
- 28 Mar, 2017 1 commit
-
-
Wiktor Garbacz authored
A step towards removing isolate from ParseInfo. Removing isolate from ParseInfo will make it easier to create and execute parse tasks on background threads. BUG=v8:6093 Change-Id: I0a3546618d01b9232014da94cf8d0f72427a0d1d Reviewed-on: https://chromium-review.googlesource.com/458006 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44176}
-
- 01 Mar, 2017 1 commit
-
-
Eric Holk authored
BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=697191 Change-Id: I01ddd6824b1a79d86944ac766f5c2070e9b0c244 Reviewed-on: https://chromium-review.googlesource.com/448317Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#43522}
-
- 20 Feb, 2017 2 commits
-
-
titzer authored
R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2703243002 Cr-Commit-Position: refs/heads/master@{#43332}
-
titzer authored
R=ahaas@chromium.org, mythria@chromium.org BUG= Review-Url: https://codereview.chromium.org/2702123003 Cr-Commit-Position: refs/heads/master@{#43312}
-
- 17 Feb, 2017 1 commit
-
-
eholk authored
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}
-