1. 17 Dec, 2018 1 commit
  2. 29 Nov, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [wasm] Add more unit tests for trap handler · 3d2bc5d0
      Andreas Haas authored
      The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
      
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Patchset 1 is the original CL.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
      Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57947}
      3d2bc5d0
  3. 27 Nov, 2018 3 commits
    • Michael Starzinger's avatar
      [heap] Fix i-cache flushing operation order. · 64d373e5
      Michael Starzinger authored
      This unifies the order of i-cache flushing and permission changing
      throughout V8. According to cctest/test-icache flushing after the
      permission change is not robust on some ARM32 and ARM64 devices.
      
      There have been observed failures of {TestFlushICacheOfExecutable} on
      some devices. So far there haven't been any observed failures of the
      corresponding {TestFlushICacheOfWritable} test.
      
      Also the order of flushing before the permission change is the natural
      order in which the GC currently performs operations. Until we see
      concrete data substantiating the opposite, the following is the
      supported and intended order throughout V8:
      
        exec -> perm(RW) -> patch -> flush -> perm(RX) -> exec
      
      This CL tries to establish said order throughout the codebase.
      
      R=ulan@chromium.org
      TEST=cctest/test-icache
      BUG=v8:8507,chromium:845877
      
      Change-Id: Ic945082e643aa2d142d222a7913a99816aff4644
      Reviewed-on: https://chromium-review.googlesource.com/c/1351025Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57869}
      64d373e5
    • Clemens Hammacher's avatar
      Revert "[wasm] Add more unit tests for trap handler" · 2fd07376
      Clemens Hammacher authored
      This reverts commit 4644b32e.
      
      Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
      
      Original change's description:
      > [wasm] Add more unit tests for trap handler
      > 
      > The unittests test if the trap handler only handles those traps it
      > is supposed to handle:
      > * Only handle traps when the thread-in-wasm flag is set.
      > * Only handle traps of the right type, i.e. memory access violations.
      > * Only handle traps at recorded instructions.
      > 
      > The tests also test the consistency of the thread-in-wasm flag. I made
      > one change in the trap handler where that consistency could be
      > violated.
      > 
      > All tests are executed with the default trap handler provided by V8,
      > and with the trap handler callback installed in a test signal/exception
      > handler.
      > 
      > Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57858}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
      
      Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/1351021Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57861}
      2fd07376
    • Andreas Haas's avatar
      [wasm] Add more unit tests for trap handler · 4644b32e
      Andreas Haas authored
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57858}
      4644b32e
  4. 21 Nov, 2018 1 commit
    • Ross McIlroy's avatar
      [AsmJs] Avoid allocation of WasmModuleObject until instantiation. · ccd8073c
      Ross McIlroy authored
      Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS
      since that is called when we are compiling the native context independent SharedFunctionInfo
      and the WasmModuleObject requires a native context. Instead save the members required to
      create the object in the AsmWasmData and create it during module instantiation. Note:
      since the Wasm module is an implementation detail for asm_wasm code and isn't exposed,
      this doeesn't have semantic change for asm.js code.
      
      As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated
      struct. Some logic is also moved from module-compiler to wasm-engine to make the
      seperation between Wasm SyncCompile and AsmJS SyncCompile more clear.
      
      BUG=chromium:900535,v8:8395
      
      Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b
      Reviewed-on: https://chromium-review.googlesource.com/c/1345509
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57704}
      ccd8073c
  5. 20 Nov, 2018 2 commits
  6. 19 Nov, 2018 1 commit
    • Ben Smith's avatar
      [wasm] Decode bulk memory instructions · 50798d60
      Ben Smith authored
      These instructions aren't implemented yet in TF or in Liftoff, but they
      are properly decoded.
      
      The table instructions (i.e. `table.{init,drop,copy}`) are validated,
      since the table and element sections occur before the code section. The
      memory instructions (i.e. `memory.{init,drop,copy,fill}`) are not
      validated because the data section occurs after the code section, so it
      can't be verified in one pass (without throwing a validation error
      later).
      
      There is currently a discussion about whether to add a new section
      (similar to `func`) that predefines the number of expected data
      segments. If we add this, then we can validate in one pass. For now,
      we'll leave it unimplemented.
      
      Bug: v8:7747
      Change-Id: I839edf51721105a47a1fa8dd5e5e1bd855e72447
      Reviewed-on: https://chromium-review.googlesource.com/c/1339241
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57622}
      50798d60
  7. 12 Nov, 2018 1 commit
  8. 29 Oct, 2018 1 commit
  9. 19 Oct, 2018 1 commit
  10. 17 Oct, 2018 2 commits
  11. 12 Oct, 2018 1 commit
  12. 18 Sep, 2018 1 commit
  13. 06 Sep, 2018 2 commits
  14. 09 Aug, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Add WasmFeatures to enable/detect features · 6aa2a253
      Ben L. Titzer authored
      This CL introduces a set of configuration options implemented as
      a struct of booleans that together comprise the set of enabled
      or detected features. The configuration options replace command-line
      flags that were checked deep in the implementation. As such, it is
      necessary to plumb them through multiple levels of abstraction.
      
      R=ahaas@chromium.org
      CC=mstarzinger@chromium.org
      BUG=chromium:868844
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637
      Reviewed-on: https://chromium-review.googlesource.com/1163670Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55018}
      6aa2a253
  15. 07 Aug, 2018 1 commit
    • Michael Starzinger's avatar
      [wasm] Support concurrent patching of jump table. · 7579b1e3
      Michael Starzinger authored
      This adds initial support for concurrently patching jump table slots. It
      is needed once different Isolates share code (for the --wasm-shared-code
      feature). We need to ensure that instructions holding the target address
      within a jump table slot do not cross cache-line boundaries. To do this,
      the jump table has been split into consecutive pages.
      
      Note that this also adds a stress test for multiple threads hammering at
      a single slot concurrently. The test is currently limited to the ia32
      and the x64 architecture, but will be extended to cover others. The test
      reliably triggers tearing of the target address on almost every run of
      the test and hence serves to prevent regressions.
      
      R=clemensh@chromium.org
      TEST=cctest/test-jump-table-assembler
      BUG=v8:8018
      
      Change-Id: Ife56bbb61ffcae5d8906ca7b8c604b195603707c
      Reviewed-on: https://chromium-review.googlesource.com/1163664
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54942}
      7579b1e3
  16. 26 Jul, 2018 1 commit
  17. 24 Jul, 2018 2 commits
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored
      This is a reland of a462a785
      
      Original change's description:
      > [turboassembler] Introduce hard-abort mode
      > 
      > For checks and assertions (mostly for debug code, like stack alignment
      > or zero extension), we had two modes: Emit a call to the {Abort}
      > runtime function (the default), and emit a debug break (used for
      > testing, enabled via --trap-on-abort).
      > In wasm, where we cannot just call a runtime function because code must
      > be isolate independent, we always used the trap-on-abort behaviour.
      > This causes problems for our fuzzers, which do not catch SIGTRAP, and
      > hence do not detect debug code failures.
      > 
      > This CL introduces a third mode ("hard abort"), which calls a C
      > function via {ExternalReference}. The C function still outputs the
      > abort reason, but does not print the stack trace. It then aborts via
      > "OS::Abort", just like the runtime function.
      > This will allow fuzzers to detect the crash and even find a nice error
      > message.
      > 
      > Even though this looks like a lot of code churn, it is actually not.
      > Most added lines are new tests, and other changes are minimal.
      > 
      > R=mstarzinger@chromium.org
      > 
      > Bug: chromium:863799
      > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      > Reviewed-on: https://chromium-review.googlesource.com/1142163
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54592}
      
      Bug: chromium:863799
      Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
      Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e
    • Michael Starzinger's avatar
      [wasm] Remove Isolate from module decoder entry points. · 131fb724
      Michael Starzinger authored
      R=ahaas@chromium.org
      
      Change-Id: I7c6fd17f36d33451ce7605e74002515295c7ad1c
      Reviewed-on: https://chromium-review.googlesource.com/1145195Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54629}
      131fb724
  18. 20 Jul, 2018 2 commits
    • Sigurd Schneider's avatar
      Speculatively revert "[turboassembler] Introduce hard-abort mode" · 039c18e1
      Sigurd Schneider authored
      This reverts commit a462a785.
      
      Reason for revert: Breaks a TurboAssembler test:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726
      
      Original change's description:
      > [turboassembler] Introduce hard-abort mode
      > 
      > For checks and assertions (mostly for debug code, like stack alignment
      > or zero extension), we had two modes: Emit a call to the {Abort}
      > runtime function (the default), and emit a debug break (used for
      > testing, enabled via --trap-on-abort).
      > In wasm, where we cannot just call a runtime function because code must
      > be isolate independent, we always used the trap-on-abort behaviour.
      > This causes problems for our fuzzers, which do not catch SIGTRAP, and
      > hence do not detect debug code failures.
      > 
      > This CL introduces a third mode ("hard abort"), which calls a C
      > function via {ExternalReference}. The C function still outputs the
      > abort reason, but does not print the stack trace. It then aborts via
      > "OS::Abort", just like the runtime function.
      > This will allow fuzzers to detect the crash and even find a nice error
      > message.
      > 
      > Even though this looks like a lot of code churn, it is actually not.
      > Most added lines are new tests, and other changes are minimal.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: chromium:863799
      > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      > Reviewed-on: https://chromium-review.googlesource.com/1142163
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54592}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:863799
      Reviewed-on: https://chromium-review.googlesource.com/1145431
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54597}
      039c18e1
    • Clemens Hammacher's avatar
      [turboassembler] Introduce hard-abort mode · a462a785
      Clemens Hammacher authored
      For checks and assertions (mostly for debug code, like stack alignment
      or zero extension), we had two modes: Emit a call to the {Abort}
      runtime function (the default), and emit a debug break (used for
      testing, enabled via --trap-on-abort).
      In wasm, where we cannot just call a runtime function because code must
      be isolate independent, we always used the trap-on-abort behaviour.
      This causes problems for our fuzzers, which do not catch SIGTRAP, and
      hence do not detect debug code failures.
      
      This CL introduces a third mode ("hard abort"), which calls a C
      function via {ExternalReference}. The C function still outputs the
      abort reason, but does not print the stack trace. It then aborts via
      "OS::Abort", just like the runtime function.
      This will allow fuzzers to detect the crash and even find a nice error
      message.
      
      Even though this looks like a lot of code churn, it is actually not.
      Most added lines are new tests, and other changes are minimal.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:863799
      Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      Reviewed-on: https://chromium-review.googlesource.com/1142163
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54592}
      a462a785
  19. 19 Jun, 2018 1 commit
  20. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Store WasmModule in shared_ptr during async compilation · 6be6ec00
      Clemens Hammacher authored
      We currently store the {WasmModule} (generated during decoding) in a
      unique_ptr and pass ownership to the {WasmModuleObject} after
      compilation.
      I plan to move the {Managed<NativeModule>} from {WasmCompiledModule} to
      {WasmModuleObject}, which will force us to create the
      {WasmModuleObject} *before* compilation, so that the {CompilationState}
      is available during compilation.
      
      This CL prepares that refactoring by storing the {WasmModule} in a
      {shared_ptr} in the {AsyncCompileJob}. Note that it will eventually be
      stored in a {shared_ptr} in the {Managed} anyway.
      
      R=titzer@chromium.org
      
      Change-Id: Iac5e3c1067af2801e938f77a455a68807801526a
      Reviewed-on: https://chromium-review.googlesource.com/1104117
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53801}
      6be6ec00
  21. 07 May, 2018 1 commit
  22. 30 Apr, 2018 1 commit
  23. 24 Apr, 2018 1 commit
  24. 06 Apr, 2018 1 commit
  25. 05 Apr, 2018 1 commit
  26. 04 Apr, 2018 2 commits
    • Ben Titzer's avatar
      Revert "[wasm] Merge the WasmContext into WasmInstanceObject" · 8adb94fc
      Ben Titzer authored
      This reverts commit 57bf0bfe.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] Merge the WasmContext into WasmInstanceObject
      > 
      > This change makes lifetime management of WasmCode much simpler.
      > By using the WasmInstanceObject as the context for WASM code execution,
      > including the pointer to the memory base and indirect function tables,
      > this keeps the instance alive when WASM code is on the stack, since
      > the instance object is passed as a parameter and spilled onto the stack.
      > This is in preparation of sharing the code between instances and
      > isolates.
      > 
      > Bug: v8:7424
      > 
      > Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      > Reviewed-on: https://chromium-review.googlesource.com/958520
      > Commit-Queue: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52361}
      
      TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7424
      Reviewed-on: https://chromium-review.googlesource.com/995418Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52364}
      8adb94fc
    • Ben L. Titzer's avatar
      [wasm] Merge the WasmContext into WasmInstanceObject · 57bf0bfe
      Ben L. Titzer authored
      This change makes lifetime management of WasmCode much simpler.
      By using the WasmInstanceObject as the context for WASM code execution,
      including the pointer to the memory base and indirect function tables,
      this keeps the instance alive when WASM code is on the stack, since
      the instance object is passed as a parameter and spilled onto the stack.
      This is in preparation of sharing the code between instances and
      isolates.
      
      Bug: v8:7424
      
      Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      Reviewed-on: https://chromium-review.googlesource.com/958520
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52361}
      57bf0bfe
  27. 23 Mar, 2018 1 commit
  28. 07 Feb, 2018 1 commit
  29. 31 Jan, 2018 1 commit
    • Karl Schimpf's avatar
      [wasm] Implement i64.trunc_s:sat/f32 · ef98172d
      Karl Schimpf authored
      Implements the saturating opcode i64.trunc_s:sat/f32.
      
      Also does some refactoring of the i32 saturating opcodes use a simplier
      solution (calling a single method to handle all i32 values).
      
      Also refactors code so that the remaining i64 saturating conversions
      should be easy to add to the wasm compiler.
      
      Bug: v8:7226
      Change-Id: I031aca1e059b4baa989a56ecbc16941f591ff9b3
      Reviewed-on: https://chromium-review.googlesource.com/887333
      Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51001}
      ef98172d
  30. 25 Jan, 2018 1 commit
  31. 18 Jan, 2018 1 commit
  32. 16 Jan, 2018 1 commit