1. 25 Apr, 2018 1 commit
    • Ben Smith's avatar
      [wasm] Implement WebAssembly.Global import/export · 6a505606
      Ben Smith authored
      The mutable-globals proposal spec allows importing as Numbers or
      WebAssembly.Global values, but always exports as WebAssembly.Global.
      
      Since the value is always boxed, we can also import/export i64 values.
      
      This CL also includes support for export of mutable globals. Since the
      underlying ArrayBuffer that stores the global's value is shared between
      the module and the WebAssembly.Global object, all that needs to be done
      is remove the validation check.
      
      Bug: v8:7625
      Change-Id: I24d763e3bc193d229a7cc33b2f2690a473c6f2bc
      Reviewed-on: https://chromium-review.googlesource.com/1018406
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52789}
      6a505606
  2. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  3. 09 Apr, 2018 1 commit
  4. 02 Feb, 2018 1 commit
  5. 20 Jun, 2016 1 commit
    • mtrofin's avatar
      [wasm] Separate compilation from instantiation · c1d01aea
      mtrofin authored
      Compilation of wasm functions happens before instantiation. Imports are linked afterwards, at instantiation time. Globals and memory are also
      allocated and then tied in via relocation at instantiation time.
      
      This paves the way for implementing Wasm.compile, a prerequisite to
      offering the compiled code serialization feature.
      
      Currently, the WasmModule::Compile method just returns a fixed array
      containing the code objects. More appropriate modeling of the compiled module to come.
      
      Opportunistically centralized the logic on how to update memory
      references, size, and globals, since that logic is the exact same on each
      architecture, except for the actual storing of values back in the
      instruction stream.
      
      BUG=v8:5072
      
      Review-Url: https://codereview.chromium.org/2056633002
      Cr-Commit-Position: refs/heads/master@{#37086}
      c1d01aea
  6. 30 Sep, 2015 1 commit
  7. 29 Apr, 2014 1 commit
  8. 08 May, 2013 1 commit
  9. 11 Nov, 2011 3 commits
  10. 22 Mar, 2011 1 commit
  11. 07 Dec, 2010 3 commits
  12. 30 Aug, 2010 1 commit
  13. 06 Oct, 2009 1 commit
  14. 02 Jun, 2009 1 commit
  15. 28 May, 2009 1 commit
  16. 25 May, 2009 1 commit
  17. 09 Sep, 2008 1 commit
  18. 03 Jul, 2008 1 commit