1. 22 Mar, 2017 1 commit
  2. 20 Mar, 2017 2 commits
  3. 17 Mar, 2017 3 commits
    • titzer's avatar
      [rename] Rename internal field to embedder field. · 72e53936
      titzer authored
      This CL renames all occurrences of "internal field" to "embedder field"
      to prevent confusion. As it turns out, these fields are not internal to
      V8, but are actually embedder provided fields that should not be mucked
      with by the internal implementation of V8.
      
      Note that WASM does use these fields, and it should not.
      
      BUG=v8:6058
      
      Review-Url: https://codereview.chromium.org/2741683004
      Cr-Commit-Position: refs/heads/master@{#43900}
      72e53936
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      neis authored
      This is a first step towards moving Turbofan code generation off the main thread.
      
      Summary of the changes:
      - AssemblerBase no longer has a pointer to the isolate. Instead, its
        constructor receives the few things that it needs from the isolate (on most
        architectures this is just the serializer_enabled flag).
      - RelocInfo no longer has a pointer to the isolate. Instead, the functions
        that need it take it as an argument.  (There are currently still a few that
        implicitly access the isolate through a HeapObject.)
      - The MacroAssembler now explicitly holds a pointer to the isolate (before, it
        used to get it from the Assembler).
      - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
        it's not used at all in the Assemblers.
      - A few architectures implemented parts of the Assembler with the help
        of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
        longer has the isolate, but the MacroAssembler still needs it, this doesn't
        work anymore.  Instead, these Assemblers now use a new PatchingAssembler.
      
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2732273003
      Cr-Commit-Position: refs/heads/master@{#43890}
      94b088ca
    • gdeepti's avatar
      [wasm] Fix DetachArrayBuffer for WebAssembly.Memory on grow · 1fce7d60
      gdeepti authored
      DetachArrayBuffer makes incorrect assumptions about the state of the ArrayBuffer. It assumes that that the ArrayBuffer is internal to wasm unless guard pages are enabled, this is not the case as the ArrayBuffer can be externalized outside of wasm, in this case through gin.
      
      BUG=chromium:700384
      
      Review-Url: https://codereview.chromium.org/2754153002
      Cr-Commit-Position: refs/heads/master@{#43880}
      1fce7d60
  4. 15 Mar, 2017 1 commit
  5. 14 Mar, 2017 1 commit
  6. 13 Mar, 2017 3 commits
    • eholk's avatar
      [wasm] Initial signal handler · 118c376f
      eholk authored
      This is basically the minimum viable signal handler for Wasm bounds checks.
      It includes the TLS check and the fine grained instructions checks. These
      two checks provide most of the safety for the signal handler. Future CLs will
      add code range and data range checks for more robustness.
      
      The trap handling code and data structures are all in src/trap-handler, with
      the code that actually runs in the signal handler confined to
      src/trap-handler/signal-handler.cc.
      
      This changes adds a new V8 API that the embedder should call from a signal
      handler that will give V8 the chance to handle the fault first. For hosts that
      do not want to implement their own signal handler, we include the option to
      install a simple one. This simple handler is also used for the tests.
      
      When a Wasm module is instantiated, information about each function is passed
      to the trap handler, which is used to classify faults. These are removed during
      the instance finalizer.
      
      Several future enhancements are planned before turning this on by default.
      Obviously, the additional checks will be added to MaybeHandleFault. We are
      also planning to add a two-level CodeObjectData table that is grouped by
      isolates to make cleanup easier and also reduce potential for contending on
      a single data structure.
      
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Original-Original-Commit-Position: refs/heads/master@{#43523}
      Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Original-Commit-Position: refs/heads/master@{#43755}
      Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Commit-Position: refs/heads/master@{#43759}
      118c376f
    • eholk's avatar
      Revert of [wasm] Initial signal handler (patchset #60 id:1170001 of... · aba151b9
      eholk authored
      Revert of [wasm] Initial signal handler (patchset #60 id:1170001 of https://codereview.chromium.org/2371833007/ )
      
      Reason for revert:
      ASAN breakage, such as https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/19111/steps/Check/logs/grow-memory
      
      Original issue's description:
      > [wasm] Initial signal handler
      >
      > This is basically the minimum viable signal handler for Wasm bounds checks.
      > It includes the TLS check and the fine grained instructions checks. These
      > two checks provide most of the safety for the signal handler. Future CLs will
      > add code range and data range checks for more robustness.
      >
      > The trap handling code and data structures are all in src/trap-handler, with
      > the code that actually runs in the signal handler confined to
      > src/trap-handler/signal-handler.cc.
      >
      > This changes adds a new V8 API that the embedder should call from a signal
      > handler that will give V8 the chance to handle the fault first. For hosts that
      > do not want to implement their own signal handler, we include the option to
      > install a simple one. This simple handler is also used for the tests.
      >
      > When a Wasm module is instantiated, information about each function is passed
      > to the trap handler, which is used to classify faults. These are removed during
      > the instance finalizer.
      >
      > Several future enhancements are planned before turning this on by default.
      > Obviously, the additional checks will be added to MaybeHandleFault. We are
      > also planning to add a two-level CodeObjectData table that is grouped by
      > isolates to make cleanup easier and also reduce potential for contending on
      > a single data structure.
      >
      > BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      >
      > Review-Url: https://codereview.chromium.org/2371833007
      > Cr-Original-Commit-Position: refs/heads/master@{#43523}
      > Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
      > Review-Url: https://codereview.chromium.org/2371833007
      > Cr-Commit-Position: refs/heads/master@{#43755}
      > Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b
      
      TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2744383002
      Cr-Commit-Position: refs/heads/master@{#43757}
      aba151b9
    • eholk's avatar
      [wasm] Initial signal handler · 338622d7
      eholk authored
      This is basically the minimum viable signal handler for Wasm bounds checks.
      It includes the TLS check and the fine grained instructions checks. These
      two checks provide most of the safety for the signal handler. Future CLs will
      add code range and data range checks for more robustness.
      
      The trap handling code and data structures are all in src/trap-handler, with
      the code that actually runs in the signal handler confined to
      src/trap-handler/signal-handler.cc.
      
      This changes adds a new V8 API that the embedder should call from a signal
      handler that will give V8 the chance to handle the fault first. For hosts that
      do not want to implement their own signal handler, we include the option to
      install a simple one. This simple handler is also used for the tests.
      
      When a Wasm module is instantiated, information about each function is passed
      to the trap handler, which is used to classify faults. These are removed during
      the instance finalizer.
      
      Several future enhancements are planned before turning this on by default.
      Obviously, the additional checks will be added to MaybeHandleFault. We are
      also planning to add a two-level CodeObjectData table that is grouped by
      isolates to make cleanup easier and also reduce potential for contending on
      a single data structure.
      
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Original-Commit-Position: refs/heads/master@{#43523}
      Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Commit-Position: refs/heads/master@{#43755}
      338622d7
  7. 06 Mar, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] Fix code specialization for empty memory buffer · 7d8a3028
      Clemens Hammacher authored
      From asm.js code we might get an empty ArrayBuffer as heap memory. In
      this case, both the old memory start and the new memory start will be
      nullptr. The size however has to be patched from default_size to 0.
      
      This CL changes code specialization to be able to either patch memory
      references, or patch memory sizes or both.
      
      R=titzer@chromium.org, ahaas@chromium.org
      BUG=chromium:698587
      
      Change-Id: I4d9d811d75cb83842f23df317e8e7fc02aeb5146
      Reviewed-on: https://chromium-review.googlesource.com/450257
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43613}
      7d8a3028
    • clemensh's avatar
      [wasm] Also unwrap exported debugged functions · 66964e68
      clemensh authored
      The previous fix (http://crrev.com/2720813002) was problematic for
      functions containing i64 parameters or returns. Those would throw a
      TypeError when called via WASM_TO_JS and JS_TO_WASM.
      
      Instead, we now unwrap the WASM_INTERPRETER_ENTRY function and call it
      directly. This removes the option to later redirect back to the
      original wasm function, but this functionality is not needed currently.
      
      Plus drive-by fix to put functions in anonymous namespace in
      wasm-compiler.cc.
      
      R=ahaas@chromium.org, titzer@chromium.org
      BUG=v8:5971, v8:5822
      
      Review-Url: https://codereview.chromium.org/2725333002
      Cr-Commit-Position: refs/heads/master@{#43603}
      66964e68
  8. 03 Mar, 2017 2 commits
    • clemensh's avatar
      [wasm] Fix importing wasm functions which are being debugged · eb36a7db
      clemensh authored
      If the imported wasm function is being debugged (i.e. redirects to the
      interpreter), call it via the JS_TO_WASM stub, such that we can disable
      the breakpoint later by patching the exported function.
      
      This also contains a drive-by fix in wasm-translation.cc (for the case
      that all known positions are bigger than the requested one).
      
      R=titzer@chromium.org, kozyatinskiy@chromium.org
      BUG=v8:5971, v8:5822
      
      Review-Url: https://codereview.chromium.org/2720813002
      Cr-Commit-Position: refs/heads/master@{#43583}
      eb36a7db
    • clemensh's avatar
      [wasm] Prepare WasmCompilationUnit for lazy compilation · 7f68cbbf
      clemensh authored
      In lazy compilation, we only compile one function at a time, and we
      might not have the wire bytes of the whole module available.
      This CL prepares the WasmCompilationUnit for this setting.
      It will also be helpful for streaming compilation.
      
      Also, the ErrorThrower (which might heap-allocate) is not stored in the
      WasmCompilationUnit any more. Instead, it is passed to the
      FinishCompilation method which is allowed to heap-allocate.
      
      R=titzer@chromium.org, ahaas@chromium.org
      BUG=v8:5991
      
      Review-Url: https://codereview.chromium.org/2726553003
      Cr-Commit-Position: refs/heads/master@{#43573}
      7f68cbbf
  9. 02 Mar, 2017 2 commits
  10. 01 Mar, 2017 2 commits
    • bmeurer's avatar
      Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of... · 0b3e554e
      bmeurer authored
      Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of https://codereview.chromium.org/2371833007/ )
      
      Reason for revert:
      Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory
      
      Original issue's description:
      > [wasm] Initial signal handler
      >
      > This is basically the minimum viable signal handler for Wasm bounds checks.
      > It includes the TLS check and the fine grained instructions checks. These
      > two checks provide most of the safety for the signal handler. Future CLs will
      > add code range and data range checks for more robustness.
      >
      > The trap handling code and data structures are all in src/trap-handler, with
      > the code that actually runs in the signal handler confined to
      > src/trap-handler/signal-handler.cc.
      >
      > This changes adds a new V8 API that the embedder should call from a signal
      > handler that will give V8 the chance to handle the fault first. For hosts that
      > do not want to implement their own signal handler, we include the option to
      > install a simple one. This simple handler is also used for the tests.
      >
      > When a Wasm module is instantiated, information about each function is passed
      > to the trap handler, which is used to classify faults. These are removed during
      > the instance finalizer.
      >
      > Several future enhancements are planned before turning this on by default.
      > Obviously, the additional checks will be added to MaybeHandleFault. We are
      > also planning to add a two-level CodeObjectData table that is grouped by
      > isolates to make cleanup easier and also reduce potential for contending on
      > a single data structure.
      >
      > BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      >
      > Review-Url: https://codereview.chromium.org/2371833007
      > Cr-Commit-Position: refs/heads/master@{#43523}
      > Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
      
      TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2723133003
      Cr-Commit-Position: refs/heads/master@{#43525}
      0b3e554e
    • eholk's avatar
      [wasm] Initial signal handler · a5af7fe9
      eholk authored
      This is basically the minimum viable signal handler for Wasm bounds checks.
      It includes the TLS check and the fine grained instructions checks. These
      two checks provide most of the safety for the signal handler. Future CLs will
      add code range and data range checks for more robustness.
      
      The trap handling code and data structures are all in src/trap-handler, with
      the code that actually runs in the signal handler confined to
      src/trap-handler/signal-handler.cc.
      
      This changes adds a new V8 API that the embedder should call from a signal
      handler that will give V8 the chance to handle the fault first. For hosts that
      do not want to implement their own signal handler, we include the option to
      install a simple one. This simple handler is also used for the tests.
      
      When a Wasm module is instantiated, information about each function is passed
      to the trap handler, which is used to classify faults. These are removed during
      the instance finalizer.
      
      Several future enhancements are planned before turning this on by default.
      Obviously, the additional checks will be added to MaybeHandleFault. We are
      also planning to add a two-level CodeObjectData table that is grouped by
      isolates to make cleanup easier and also reduce potential for contending on
      a single data structure.
      
      BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
      
      Review-Url: https://codereview.chromium.org/2371833007
      Cr-Commit-Position: refs/heads/master@{#43523}
      a5af7fe9
  11. 27 Feb, 2017 1 commit
  12. 24 Feb, 2017 1 commit
  13. 20 Feb, 2017 4 commits
  14. 31 Jan, 2017 1 commit
  15. 30 Jan, 2017 1 commit
  16. 28 Jan, 2017 1 commit
  17. 26 Jan, 2017 1 commit
    • gdeepti's avatar
      [wasm] Memory buffer should be detached after Memory.Grow · e6d13999
      gdeepti authored
      Memory.Grow should detach the ArrayBuffer associated with the Mem object after Grow. Currently, when guard pages are enabled protection is changed to make more of the buffer accessible. This does not work for when the buffer should be detached after grow, because the memory object has a reference to the same buffer befor/after grow.
      
      R=titzer@chromium.org, eholk@chromium.org
      
      Review-Url: https://codereview.chromium.org/2653183003
      Cr-Commit-Position: refs/heads/master@{#42717}
      e6d13999
  18. 24 Jan, 2017 6 commits
  19. 23 Jan, 2017 2 commits
  20. 20 Jan, 2017 2 commits
  21. 19 Jan, 2017 1 commit