1. 27 Oct, 2017 1 commit
  2. 05 Oct, 2017 1 commit
  3. 28 Sep, 2017 1 commit
  4. 11 Sep, 2017 2 commits
  5. 07 Sep, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Avoid executing infinite loops in the wasm fuzzers · 7b53a0e0
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47874}
      7b53a0e0
  6. 04 Sep, 2017 1 commit
  7. 01 Sep, 2017 1 commit
  8. 29 Aug, 2017 2 commits
  9. 28 Aug, 2017 1 commit
  10. 25 Aug, 2017 1 commit
  11. 09 Aug, 2017 1 commit
  12. 03 Aug, 2017 1 commit
  13. 18 Jul, 2017 1 commit
  14. 11 Jul, 2017 1 commit
  15. 22 Jun, 2017 1 commit
    • Andreas Haas's avatar
      [wasm][fuzzer] Handle Interpreter step limit exhaustion. · d1f566c6
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46140}
      d1f566c6
  16. 21 Jun, 2017 1 commit
  17. 13 Jun, 2017 1 commit
  18. 12 Jun, 2017 3 commits
  19. 09 Jun, 2017 1 commit
  20. 31 May, 2017 1 commit
  21. 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
  22. 17 May, 2017 1 commit
  23. 12 May, 2017 1 commit
  24. 08 May, 2017 1 commit
  25. 02 May, 2017 1 commit
  26. 28 Apr, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Move the wasm fuzzer corpus to a different directory · 1f629aac
      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: 's avatarBrad Nelson <bradnelson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44991}
      1f629aac
  27. 27 Apr, 2017 1 commit
  28. 25 Apr, 2017 2 commits
    • 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
    • Andreas Haas's avatar
      [wasm] Update wasm fuzzer corpus · e34a9964
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44832}
      e34a9964
  29. 07 Apr, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Implement extensible name section · 1a73f73b
      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: 's avatarAndreas Rossberg <rossberg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44492}
      1a73f73b
  30. 04 Apr, 2017 1 commit
  31. 28 Mar, 2017 1 commit
  32. 01 Mar, 2017 1 commit
  33. 20 Feb, 2017 2 commits
  34. 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