1. 21 Jun, 2017 1 commit
  2. 13 Jun, 2017 1 commit
  3. 31 May, 2017 1 commit
  4. 19 May, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Cleanup the wasm fuzzer corpus files. · 2f92e9eb
      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: 's avatarMichael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45417}
      2f92e9eb
  5. 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
  6. 24 Oct, 2016 1 commit
  7. 14 Sep, 2016 1 commit
    • ahaas's avatar
      [wasm] Write fuzzers for single wasm sections. · 3ff20190
      ahaas authored
      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}
      3ff20190
  8. 29 Aug, 2016 1 commit
  9. 03 Jun, 2016 1 commit
    • machenbach's avatar
      [gn] Add fuzzer targets. · 63526069
      machenbach authored
      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}
      63526069
  10. 02 Mar, 2016 1 commit
  11. 02 Feb, 2016 2 commits
  12. 01 Feb, 2016 1 commit
  13. 26 Jan, 2016 1 commit