Skip to content

V
V8
Switch branch/tag
  1. 02 Feb, 2018 1 commit
  3. 30 Jan, 2018 3 commits
  5. 11 Jan, 2018 1 commit
  7. 04 Jan, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm][fuzzer] Add locals · 4b107b9e
      Clemens Hammacher authored 
      This adds support for get_local and set_local to the wasm compile
fuzzer. Each function will have between 0 and 32 locals of random type.
For set_local, we generate a value of the respective type and store it
in the local. For get_local, we load any local and convert it to the
wanted type.
Note that with get_local, we now also check that parameters are passed
correctly between functions.

Drive-by: Fix parameters passed to the main function (was [1,2,3] for
the interpreter, but [1,1,1] for compiled code).

R=ahaas@chromium.org, eholk@chromium.org

Change-Id: I38e85fe25b1fb4ac298fa81ec8e33711294e78bb
Reviewed-on: https://chromium-review.googlesource.com/847535Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50355}
      4b107b9e
  9. 21 Dec, 2017 3 commits
  11. 15 Nov, 2017 1 commit
  13. 09 Nov, 2017 1 commit
  15. 08 Nov, 2017 2 commits
  17. 07 Nov, 2017 1 commit
  19. 06 Nov, 2017 3 commits
  21. 04 Sep, 2017 1 commit
  23. 01 Sep, 2017 1 commit
  25. 29 Aug, 2017 1 commit
  27. 09 Aug, 2017 1 commit
  29. 18 Jul, 2017 1 commit
  31. 12 May, 2017 1 commit
  33. 08 May, 2017 1 commit
  35. 25 Apr, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Reuse LEB encoding logic in module builder · 4531c865
      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: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44842}
      4531c865
  37. 01 Mar, 2017 1 commit
  39. 20 Feb, 2017 1 commit
  41. 17 Feb, 2017 1 commit
    • eholk's avatar
      [wasm] Syntax- and Type-aware Fuzzer · 3e1db847
      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}
      3e1db847