1. 06 Aug, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Check size of tables dynamically · 47434265
      Andreas Haas authored
      We used to check the size of tables at compile time, and threw a
      CompilationError if a given size exceeded the implementation-defined
      limit. However, the spec defines that an error should only be thrown
      when the implementation-defined limit is reached, which is either at
      instantiation time of during runtime at a table.grow.
      
      With this CL the V8 implementation becomes spec compliant in this
      regard.
      
      R=jkummerow@chromium.org
      
      Bug: v8:10556
      Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69267}
      47434265
  2. 16 Jun, 2020 1 commit
  3. 12 Jun, 2020 1 commit
  4. 04 Dec, 2019 1 commit
  5. 29 Nov, 2019 1 commit
  6. 30 Apr, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Refactor WasmTableObject::Grow · c7627bbc
      Andreas Haas authored
      This CL refactors WasmTableObject::Grow to make it usable for the
      table.grow instruction of WebAssembly.
      
      The refactored version of WasmTableObject::Grow does additionally:
      * Check if growing is possible
      * Grow the FixedArray backing store of the table and initialize the new
        fields.
      * Calculate the return value of WasmTableObject::Grow.
      
      R=jkummerow@chromium.org
      
      Bug: v8:7581
      Change-Id: Ic6c867b96c30bd987ea281d5b3515a04bc5a3900
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588136
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61112}
      c7627bbc
  7. 13 Mar, 2019 1 commit
  8. 12 Mar, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Fix insufficient bounds check in WebAssembly.get · e162eb44
      Andreas Haas authored
      According to the wasm js-spec, the table index can be uint32. The
      implementation in our implementation expected an int though. We did not
      check for the int overflow.
      
      I replaced the throwing of the exception in WasmTableObject::Get to use
      the ErrorThrower instead of throwing the exception with Isolate::Throw
      directly. The reason is that I see with other CL's that I have to throw
      several errors, and I don't want to introduce a new message and
      MessageId for every error. Moreover, the ErrorThrower is a standard way
      in wasm to throw errors. It feels right to throw the error the same way
      here.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:940296
      Change-Id: Idb77c813506fe66a3192b66fe0e8e807b80580ab
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514496
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60181}
      e162eb44
  9. 08 Mar, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Construct WasmExportedFunctions for table elements lazily · 27540226
      Andreas Haas authored
      We have to create WasmExportedFunction objects for any WebAssembly
      function which may escape a WebAssembly instance. Up until now we
      created these WasmExportedFunction objects eagerly during instantiation
      time: for any exported function, and any element in an exported table we
      create such an object.
      
      With the anyref proposal, the table.get instruction can allow any
      function in a table to escape its instance. Therefore we would have to
      create a WasmExportedFunction object for any function which is put into
      a table.
      
      With this CL we create WasmExportedFunctions for table entries lazily.
      We initialize tables with placeholders consisting of the instance and
      the function index. If we encounter a placeholder in table.get, we
      create the WasmExportedFunction for the expected function to return it.
      
      R=mstarzinger@chromium.org
      CC=titzer@chromium.org
      
      Bug: v8:7581
      Change-Id: I4f32bd7433285d0b04a22c0fb70b736bac55b3f1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1505575Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60115}
      27540226
  10. 05 Mar, 2019 1 commit
    • Sven Sauleau's avatar
      [wasm] correct Table limit · f4e322c3
      Sven Sauleau authored
      Align the Table implementation limits with the JavaScript Embedding
      limits defined in the specification (from MAX_UINT32 to 1e7).
      
      Introduce a new helper (max_table_init_entries) that returns the
      maximum number of Table entry at initialization. It takes into account
      the maximum Table size, which can be passed by a flag.
      
      Bug: v8:8633
      Change-Id: Idfa19418e81f478f7886a30876e66c9b216e25ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1496971
      Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60036}
      f4e322c3
  11. 01 Mar, 2019 1 commit
  12. 06 Feb, 2019 1 commit
  13. 30 Jan, 2019 1 commit
  14. 22 Jan, 2019 1 commit
  15. 19 Jan, 2019 1 commit
  16. 18 Jan, 2019 1 commit
    • Sven Sauleau's avatar
      [wasm] fix js-api table/grow · fc277117
      Sven Sauleau authored
      Fix WebAssembly's table/grow js-api. The argument is a unsigned long,
      this change refactors most of arithmetic and bounds checks type from
      int64 to uint32_t, according to the spec.
      
      Bug: v8:8319
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Change-Id: Ia29121c930d7fb930668e54a5a769dae25234f2c
      Reviewed-on: https://chromium-review.googlesource.com/c/1351006
      Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58936}
      fc277117
  17. 07 Jan, 2019 1 commit
  18. 10 Dec, 2018 1 commit
    • Sven Sauleau's avatar
      [wasm] fix js-api Memory and Table constructor · ff6544c5
      Sven Sauleau authored
      Fix and re-enable tests for WebAssembly's memory/constructor and
      table/constructor js-api.
      
      It introduces the '[EnforceRange] unsigned long' algorithm used
      to validate initial and maximum properties.
      
      The initial property is now required, by the switch to the Web IDL
      specification. Most of the input validations errors are now considered
      TypeError instead of RangeError.
      
      The WasmTableObject and WasmMemoryObject APIs use more consistently uint32_t
      to ensure integer range and remove the need for bounds checks.
      
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Bug: v8:8319
      Change-Id: Iedd3ee6484ef688a5e96f93006eb6ca66d805a48
      Reviewed-on: https://chromium-review.googlesource.com/c/1354043
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58138}
      ff6544c5
  19. 07 Dec, 2018 1 commit
  20. 06 Dec, 2018 1 commit
  21. 05 Dec, 2018 1 commit
  22. 10 Oct, 2018 1 commit
  23. 20 Nov, 2017 1 commit
  24. 25 Oct, 2017 1 commit
  25. 23 Oct, 2017 1 commit
  26. 16 Oct, 2017 1 commit
  27. 09 Oct, 2017 1 commit
  28. 05 Sep, 2017 1 commit
  29. 03 Aug, 2017 2 commits
  30. 02 Aug, 2017 1 commit
  31. 02 Jun, 2017 1 commit
  32. 18 Apr, 2017 1 commit
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 71cf4890
      mtrofin authored
      Today, the semantics of:
      
      WebAssembly.instantiate
      
      and
      
      WebAssembly.compile().then(new WebAssemblyInstance)
      
      are subtly different, to the point where attempting the proposed
      change uncovered bugs.
      
      In the future, it's possible that .instantiate actually have different
      semantics - if we pre-specialized to the provided ffi, for example.
      Right now that's not the case.
      
      This CL:
      - gets our implementation closer to what developers may write using
      the compile -> new Instance alternative, in particular wrt promise
      creation. By reusing code paths, we uncover more bugs, and keep
      maintenance cost lower.
      
      - it gives us the response-based WebAssembly.instantiate implicitly.
      Otherwise, we'd need that same implementation on the blink side. The
      negative is maintenance: imagine if the bugs I mentioned could only be
      found when running in Blink.
      
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2806073002
      Cr-Original-Commit-Position: refs/heads/master@{#44592}
      Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb
      Review-Url: https://codereview.chromium.org/2806073002
      Cr-Commit-Position: refs/heads/master@{#44669}
      71cf4890
  33. 12 Apr, 2017 2 commits
    • hablich's avatar
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6... · d3f1d5c5
      hablich authored
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ )
      
      Reason for revert:
      Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824
      
      Original issue's description:
      > [wasm] instantiate expressed in terms of compile
      >
      > Today, the semantics of:
      >
      > WebAssembly.instantiate
      >
      > and
      >
      > WebAssembly.compile().then(new WebAssemblyInstance)
      >
      > are subtly different, to the point where attempting the proposed
      > change uncovered bugs.
      >
      > In the future, it's possible that .instantiate actually have different
      > semantics - if we pre-specialized to the provided ffi, for example.
      > Right now that's not the case.
      >
      > This CL:
      > - gets our implementation closer to what developers may write using
      > the compile -> new Instance alternative, in particular wrt promise
      > creation. By reusing code paths, we uncover more bugs, and keep
      > maintenance cost lower.
      >
      > - it gives us the response-based WebAssembly.instantiate implicitly.
      > Otherwise, we'd need that same implementation on the blink side. The
      > negative is maintenance: imagine if the bugs I mentioned could only be
      > found when running in Blink.
      >
      > BUG=chromium:697028
      >
      > Review-Url: https://codereview.chromium.org/2806073002
      > Cr-Commit-Position: refs/heads/master@{#44592}
      > Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb
      
      TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2810203002
      Cr-Commit-Position: refs/heads/master@{#44614}
      d3f1d5c5
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 7829af32
      mtrofin authored
      Today, the semantics of:
      
      WebAssembly.instantiate
      
      and
      
      WebAssembly.compile().then(new WebAssemblyInstance)
      
      are subtly different, to the point where attempting the proposed
      change uncovered bugs.
      
      In the future, it's possible that .instantiate actually have different
      semantics - if we pre-specialized to the provided ffi, for example.
      Right now that's not the case.
      
      This CL:
      - gets our implementation closer to what developers may write using
      the compile -> new Instance alternative, in particular wrt promise
      creation. By reusing code paths, we uncover more bugs, and keep
      maintenance cost lower.
      
      - it gives us the response-based WebAssembly.instantiate implicitly.
      Otherwise, we'd need that same implementation on the blink side. The
      negative is maintenance: imagine if the bugs I mentioned could only be
      found when running in Blink.
      
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2806073002
      Cr-Commit-Position: refs/heads/master@{#44592}
      7829af32
  34. 11 Apr, 2017 1 commit
  35. 06 Apr, 2017 1 commit
  36. 03 Apr, 2017 2 commits
  37. 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