1. 07 Dec, 2017 1 commit
    • Karl Schimpf's avatar
      [wasm] First step of refactoring trap handling to be per module. · 0d5de9ad
      Karl Schimpf authored
      The previous code assumed that trap handling was a global concept, defined
      by function trap_handler::UseTrapHandler(). This CL does the first step
      in changing the decision to be specifiable at a module level.
      
      Therefore trap_handler::UseTrapHandler() is replaced by
      trap_handler::IsTrapHandlerEnabled(), and communicates if compilation
      supports the use of trap handlers (but still allowing the use of
      bounds checking on memory accesses).
      
      It then refactors the classes ModuleEnv and WasmCompiledModule to have
      a field "use_trap_handler" that specifies if traps should be used for
      the memory accesses in the module being compiled.
      
      Bug: v8:7143
      Change-Id: I9844842d5721c86c2dd55e911b42bf8b9922cf63
      Reviewed-on: https://chromium-review.googlesource.com/802322
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49915}
      0d5de9ad
  2. 28 Nov, 2017 3 commits
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] JIT using WasmCodeManager"" · b03b1bd9
      Mircea Trofin authored
      This reverts commit b301203e.
      
      Reason for revert: Fixed issues on arm.
      
      Original change's description:
      > Revert "[wasm] JIT using WasmCodeManager"
      > 
      > This reverts commit d4c8393c.
      > 
      > Reason for revert: Breaks ARM hardware:
      > https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268
      > 
      > Original change's description:
      > > [wasm] JIT using WasmCodeManager
      > > 
      > > This is the first step towards wasm code sharing. This CL moves wasm
      > > code generation outside the JavaScript GC heap using the previously -
      > > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      > > flag).
      > > 
      > > See design document: go/wasm-on-native-heap-stage-1
      > > 
      > > This CL doesn't change other wasm architectural invariants. We still
      > > have per-Isolate wasm code generation, and per-wasm module instance
      > > code specialization.
      > > 
      > > Bug:v8:6876
      > > 
      > > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      > > Reviewed-on: https://chromium-review.googlesource.com/674086
      > > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > > Reviewed-by: Eric Holk <eholk@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#49689}
      > 
      > TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      > 
      > Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6876
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/794690
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49691}
      
      TBR=bradnelson@chromium.org,machenbach@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: I1b07638d1bb2ba0664305b4b2dcfc1342dc8444f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6876
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/794434
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49692}
      b03b1bd9
    • Michael Achenbach's avatar
      Revert "[wasm] JIT using WasmCodeManager" · b301203e
      Michael Achenbach authored
      This reverts commit d4c8393c.
      
      Reason for revert: Breaks ARM hardware:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268
      
      Original change's description:
      > [wasm] JIT using WasmCodeManager
      > 
      > This is the first step towards wasm code sharing. This CL moves wasm
      > code generation outside the JavaScript GC heap using the previously -
      > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      > flag).
      > 
      > See design document: go/wasm-on-native-heap-stage-1
      > 
      > This CL doesn't change other wasm architectural invariants. We still
      > have per-Isolate wasm code generation, and per-wasm module instance
      > code specialization.
      > 
      > Bug:v8:6876
      > 
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      > Reviewed-on: https://chromium-review.googlesource.com/674086
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49689}
      
      TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6876
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/794690Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49691}
      b301203e
    • Mircea Trofin's avatar
      [wasm] JIT using WasmCodeManager · d4c8393c
      Mircea Trofin authored
      This is the first step towards wasm code sharing. This CL moves wasm
      code generation outside the JavaScript GC heap using the previously -
      introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      flag).
      
      See design document: go/wasm-on-native-heap-stage-1
      
      This CL doesn't change other wasm architectural invariants. We still
      have per-Isolate wasm code generation, and per-wasm module instance
      code specialization.
      
      Bug:v8:6876
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      Reviewed-on: https://chromium-review.googlesource.com/674086Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49689}
      d4c8393c
  3. 16 Oct, 2017 1 commit
  4. 11 Oct, 2017 3 commits
    • Eric Holk (eholk)'s avatar
      Reland "Reland "[wasm] trap handlers: fall back on old signal handler"" · 1117da83
      Eric Holk (eholk) authored
      This is a reland of cc237d87
      Original change's description:
      > Reland "[wasm] trap handlers: fall back on old signal handler"
      > 
      > This is a reland of ee4fe896
      > Original change's description:
      > > [wasm] trap handlers: fall back on old signal handler
      > > 
      > > This is primarily needed to test D8 under ASan. ASan installs a signal handler
      > > early in the process startup to show stack traces from crashes. We need to make
      > > sure that if V8 does not handle a signal then the existing handler gets a
      > > chance.
      > > 
      > > This change only applies when using V8's default signal handler. When
      > > integrating with the embedder's signal handler the behavior is unchanged.
      > > 
      > > Bug: chromium:771948
      > > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      > > Reviewed-on: https://chromium-review.googlesource.com/705823
      > > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > > Commit-Queue: Eric Holk <eholk@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#48429}
      > 
      > Bug: chromium:771948
      > Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
      > Reviewed-on: https://chromium-review.googlesource.com/710114
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48435}
      
      Bug: chromium:771948
      Change-Id: I781dfe356a728760090b6ccfa58212096e8f20c8
      Reviewed-on: https://chromium-review.googlesource.com/713956Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48474}
      1117da83
    • Michael Achenbach's avatar
      Revert "Reland "[wasm] trap handlers: fall back on old signal handler"" · 33d4e209
      Michael Achenbach authored
      This reverts commit cc237d87.
      
      Reason for revert: breaks win clang:
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/8538
      
      Original change's description:
      > Reland "[wasm] trap handlers: fall back on old signal handler"
      > 
      > This is a reland of ee4fe896
      > Original change's description:
      > > [wasm] trap handlers: fall back on old signal handler
      > > 
      > > This is primarily needed to test D8 under ASan. ASan installs a signal handler
      > > early in the process startup to show stack traces from crashes. We need to make
      > > sure that if V8 does not handle a signal then the existing handler gets a
      > > chance.
      > > 
      > > This change only applies when using V8's default signal handler. When
      > > integrating with the embedder's signal handler the behavior is unchanged.
      > > 
      > > Bug: chromium:771948
      > > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      > > Reviewed-on: https://chromium-review.googlesource.com/705823
      > > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > > Commit-Queue: Eric Holk <eholk@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#48429}
      > 
      > Bug: chromium:771948
      > Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
      > Reviewed-on: https://chromium-review.googlesource.com/710114
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48435}
      
      TBR=mseaborn@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org,mark@chromium.org
      
      Change-Id: If71f61ae186fc6be2006edeb2dffd7e2b6827d91
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:771948
      Reviewed-on: https://chromium-review.googlesource.com/711854Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48436}
      33d4e209
    • Eric Holk's avatar
      Reland "[wasm] trap handlers: fall back on old signal handler" · cc237d87
      Eric Holk authored
      This is a reland of ee4fe896
      Original change's description:
      > [wasm] trap handlers: fall back on old signal handler
      > 
      > This is primarily needed to test D8 under ASan. ASan installs a signal handler
      > early in the process startup to show stack traces from crashes. We need to make
      > sure that if V8 does not handle a signal then the existing handler gets a
      > chance.
      > 
      > This change only applies when using V8's default signal handler. When
      > integrating with the embedder's signal handler the behavior is unchanged.
      > 
      > Bug: chromium:771948
      > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      > Reviewed-on: https://chromium-review.googlesource.com/705823
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48429}
      
      Bug: chromium:771948
      Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
      Reviewed-on: https://chromium-review.googlesource.com/710114Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48435}
      cc237d87
  5. 10 Oct, 2017 2 commits
    • Eric Holk's avatar
      Revert "[wasm] trap handlers: fall back on old signal handler" · 0a97c51f
      Eric Holk authored
      This reverts commit ee4fe896.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] trap handlers: fall back on old signal handler
      > 
      > This is primarily needed to test D8 under ASan. ASan installs a signal handler
      > early in the process startup to show stack traces from crashes. We need to make
      > sure that if V8 does not handle a signal then the existing handler gets a
      > chance.
      > 
      > This change only applies when using V8's default signal handler. When
      > integrating with the embedder's signal handler the behavior is unchanged.
      > 
      > Bug: chromium:771948
      > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      > Reviewed-on: https://chromium-review.googlesource.com/705823
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48429}
      
      TBR=mseaborn@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org,mark@chromium.org
      
      Change-Id: Ib43b096831b15c312b3b460e59f268d5ea903f21
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:771948
      Reviewed-on: https://chromium-review.googlesource.com/710034Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48430}
      0a97c51f
    • Eric Holk's avatar
      [wasm] trap handlers: fall back on old signal handler · ee4fe896
      Eric Holk authored
      This is primarily needed to test D8 under ASan. ASan installs a signal handler
      early in the process startup to show stack traces from crashes. We need to make
      sure that if V8 does not handle a signal then the existing handler gets a
      chance.
      
      This change only applies when using V8's default signal handler. When
      integrating with the embedder's signal handler the behavior is unchanged.
      
      Bug: chromium:771948
      Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      Reviewed-on: https://chromium-review.googlesource.com/705823Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48429}
      ee4fe896
  6. 27 Sep, 2017 3 commits
  7. 25 Sep, 2017 1 commit
  8. 19 Sep, 2017 1 commit
  9. 17 Aug, 2017 1 commit
  10. 10 Aug, 2017 1 commit
  11. 28 Jun, 2017 1 commit
  12. 22 May, 2017 1 commit
  13. 27 Mar, 2017 1 commit
    • Eric Holk's avatar
      [wasm] clear and set thread-in-wasm flag on runtime calls · b7e94287
      Eric Holk authored
      This was causing GC stress failures. Garbage collections can happen during
      runtime calls, such was WasmStackGuard. If the collection cleans up Wasm
      objects, then they will have to modify the trap handler data structures, which
      requires taking a lock. This lock can only be taken if the thread-in-wasm flag
      is clear. We were getting crashes because this flag was not clear.
      
      This change fixes the issue by making sure any runtime calls from Wasm clear the
      thread-in-wasm flag and then restore it upon return. In addition, it cleans up
      the code by adding a helper function that generates the code to modify the flag.
      
      BUG= v8:6132
      
      Change-Id: I95d43388dff60ba792c57fe13448a40a02ed4802
      Reviewed-on: https://chromium-review.googlesource.com/458698
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44165}
      b7e94287
  14. 15 Mar, 2017 1 commit
  15. 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
  16. 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
  17. 31 Jan, 2017 1 commit
  18. 30 Nov, 2016 1 commit