- 07 Dec, 2017 1 commit
-
-
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:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49915}
-
- 28 Nov, 2017 3 commits
-
-
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:
Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49692}
-
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:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#49691}
-
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:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49689}
-
- 16 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
Instead of modifying this flag in compiled wasm code, we can just change it in the caller / called code. This saves code space and compilation time and fixes the referenced bug. R=titzer@chromium.org, eholk@chromium.org Bug: chromium:773631, v8:5277 Change-Id: I095158ac01eecd21a92649a3990e8d7c593db912 Reviewed-on: https://chromium-review.googlesource.com/712597Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Eric Holk <eholk@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48602}
-
- 11 Oct, 2017 3 commits
-
-
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:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48474}
-
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:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48436}
-
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:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48435}
-
- 10 Oct, 2017 2 commits
-
-
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:
Eric Holk <eholk@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48430}
-
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:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48429}
-
- 27 Sep, 2017 3 commits
-
-
Clemens Hammacher authored
Since code objects cannot grow larger than 2GB anyway, it's enough to store the instruction offset and landing pad offset as 32-bit values. This reduces the size of the ProtectedInstructionData struct by 50%. R=eholk@chromium.org Bug: v8:5277 Change-Id: I4d2e0dc76b8a853fb50d51d70d5ec4038ee594ac Reviewed-on: https://chromium-review.googlesource.com/686757 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48192}
-
Eric Holk (eholk) authored
This is the first of a series of refactoring CLs to make way for Windows trap handling support. See https://chromium-review.googlesource.com/c/v8/v8/+/626558 as well. Bug: Change-Id: I5fe9ef9c1cec58a81e51fcffbbe4419e0e298ab7 Reviewed-on: https://chromium-review.googlesource.com/644104Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48191}
-
Eric Holk authored
This CL includes validation code for the trap handler data structures in debug mode to help catch issues like v8:6841 sooner in the future. We also now eagerly initialize the free list pointers to make the logic of finding the next free entry more obvious. Bug: v8:5277 Change-Id: I13c3180c59b6152508c480e2042072a91e6ca977 Reviewed-on: https://chromium-review.googlesource.com/674128 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48186}
-
- 25 Sep, 2017 1 commit
-
-
Eric Holk authored
Previously, we would blindly register new handler data, leading to us leaking the old handler data. This meant we could then end up with overlapping handler data where the instruction offset and landing pads didn't line up right. Bug: v8:6841 Change-Id: Iedcd75925b8d9d59c8f9accf288cae954fdc568f Reviewed-on: https://chromium-review.googlesource.com/677632 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48144}
-
- 19 Sep, 2017 1 commit
-
-
Eric Holk authored
This is primarily to aid in testing the Wasm out of bounds trap handler. We keep track of how many faults have been recovered by the Wasm trap handler. This count is exposed to JavaScript through a testing-only runtime function. This allows tests to verify whether the trap handler is actually running. Bug: v8:5277 Change-Id: Ie8037a36d84eb08166c6e40c7225d912683d5786 Reviewed-on: https://chromium-review.googlesource.com/665968 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48076}
-
- 17 Aug, 2017 1 commit
-
-
Ben Noordhuis authored
glibc before 2.17 has a bug that makes it impossible to execute binaries that have single-byte thread-local variables: % node --version node: error while loading shared libraries: cannot allocate memory in static TLS block Work around that by making the one instance in the V8 code base an int. See: https://sourceware.org/bugzilla/show_bug.cgi?id=14898 See: https://github.com/nodesource/distributions/issues/513 See: https://github.com/nodejs/build/pull/809 Change-Id: Iefd8009100cd93e26cf8dc5dc03f2d622b423385 Reviewed-on: https://chromium-review.googlesource.com/612351 Commit-Queue: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-by:
Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47400}
-
- 10 Aug, 2017 1 commit
-
-
Eric Holk authored
Bug: Change-Id: I1ab93d5b2d02d9a4851c2e67d33968a7cafaedd3 Reviewed-on: https://chromium-review.googlesource.com/610892Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Commit-Queue: Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#47294}
-
- 28 Jun, 2017 1 commit
-
-
Jochen Eisinger authored
Specifically for base and libplatform I was the only owner. Adding mlippautz@ there. R=danno@chromium.org Change-Id: I246b72141abc932d9caf7dcb7485e458283d4a9f Reviewed-on: https://chromium-review.googlesource.com/551899Reviewed-by:
Daniel Clifford <danno@chromium.org> Commit-Queue: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#46275}
-
- 22 May, 2017 1 commit
-
-
Jochen Eisinger authored
R=danno@chromium.org CC=sshruthi@chromium.org TBR=verwaest@chromium.org,bmeurer@chromium.org,yangguo@chromium.org,rossberg@chromium.org Change-Id: I32e09193fa6e847ac3336eab62b6d85c46d71164 Reviewed-on: https://chromium-review.googlesource.com/509508 Commit-Queue: Jochen Eisinger <jochen@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#45447}
-
- 27 Mar, 2017 1 commit
-
-
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:
Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#44165}
-
- 15 Mar, 2017 1 commit
-
-
Eric Holk authored
Android sets both V8_OS_ANDROID and V8_OS_LINUX. For the Wasm trap handler, the difference between these OSes matters. BUG= chromium:701590 Change-Id: I5ae703a1d932c8a63e499ad39a057ad1871a2ab1 Reviewed-on: https://chromium-review.googlesource.com/455556 Commit-Queue: Eric Holk <eholk@chromium.org> Commit-Queue: Brad Nelson <bradnelson@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#43807}
-
- 13 Mar, 2017 3 commits
-
-
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}
-
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}
-
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}
-
- 01 Mar, 2017 2 commits
-
-
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}
-
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}
-
- 31 Jan, 2017 1 commit
-
-
eholk authored
Previously this information was encoded in a FixedArray dangling off the Code object. This extra field seems to be responsible for increased memory usage, as seen in the linked bugs. In this change, we instead encode this in the RelocInfo and remove the field from the Code object. BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=678583 BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=671180 BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=670733 Review-Url: https://codereview.chromium.org/2651833003 Cr-Commit-Position: refs/heads/master@{#42802}
-
- 30 Nov, 2016 1 commit
-
-
eholk authored
During codegen, we build a list mapping protected instructions to their associated landing pads. This will ultimately by used by the signal handler to recover from out of bounds faults and throw a JS exception. This is mostly pulled from my larger in-progress CL at https://codereview.chromium.org/2371833007/. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2500443004 Cr-Commit-Position: refs/heads/master@{#41400}
-