- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 30 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
Building on linux x64 with "is_component_build = true" currently fails with linker errors (undefined references). This CL fixes that. R=ahaas@chromium.org TBR=mseaborn@chromium.org,mark@chromium.org Bug: v8:8532 Change-Id: I6b32c00bd974a22268ad1f161ce06a9ebe47c805 Reviewed-on: https://chromium-review.googlesource.com/c/1356505Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57960}
-
- 29 Nov, 2018 1 commit
-
-
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: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57947}
-
- 20 Nov, 2018 1 commit
-
-
Andreas Haas authored
In the chrome-side implementation I currently use the default trap handlers of V8, see https://crrev.com/c/1290955 Bug: chromium:906565 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I74c5a18c479ad1c69303d104ad4f040de436c4e7 Reviewed-on: https://chromium-review.googlesource.com/c/1282960 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57636}
-
- 30 Oct, 2018 1 commit
-
-
Andreas Haas authored
This is the V8 side of the implementation. You can take a look at a prototype of the Chrome side changes in https://crrev.com/c/1273043. Chrome could also use V8's default implementation of the trap handler, see https://crrev.com/c/1290952. Bug: v8:6743 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I9bb3e717db17a4f30bbb8acfd80a1f6510d463ff Reviewed-on: https://chromium-review.googlesource.com/c/1283111 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57117}
-
- 26 Oct, 2018 1 commit
-
-
Andreas Haas authored
This CL refactors the existing trap handler code for Linux to allow a cleaner extension to Windows. 1) The CL extracts platform-specific code into separate files, see https://docs.google.com/document/d/1HCgKIpdjy_CEodTLvZ5VuykDI6gGTHrTtau2j0zwm28. Specifically this means: * Move posix-specific API functions from v8.h to v8-wasm-trap-handler-posix.h. Deprecate the existing TryHandleSignal API function. * Move posix-specific function declarations from trap-handler-internal.h to handler-inside-posix.h * Move posix-specific function definitions from handler-shared.cc to handler-outside-posix.cc 2) The CL changes filenames from *-linux.* to *-posix.*. I expect that most of the implementation for MacOS will be the same as for Linux. Bug: v8:6743 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I4bb7f199564a2f01042084d15a82311d11a93c7b Reviewed-on: https://chromium-review.googlesource.com/c/1280324 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57028}
-
- 20 Sep, 2018 1 commit
-
-
Florian Sattler authored
Fixing clang-tidy warning. Bug: v8:8015 Change-Id: I5686fa0c1ed73b17f592a012b00c08c575ae5387 Reviewed-on: https://chromium-review.googlesource.com/1234234Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Florian Sattler <sattlerf@google.com> Cr-Commit-Position: refs/heads/master@{#56062}
-
- 29 Aug, 2018 1 commit
-
-
Andreas Haas authored
{ThreadInWasmScope} in only used in a single location, which is in a test. It does not look like many more such places will show up. R=titzer@chromium.org, Bug: v8:8015 Change-Id: I89f6f7e2bd13e2882e65f7657d73ba59a6c71757 Reviewed-on: https://chromium-review.googlesource.com/1193446 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55486}
-
- 18 Jul, 2018 1 commit
-
-
Clemens Hammacher authored
Avoid the C-call to switch the flag, just store to the address directly. Since js-to-wasm wrappers are still isolate dependent, we just store the address of the thread-local flag in the isolate (in ThreadLocalTop) and update it if threads are switched. R=ahaas@chromium.org, mstarzinger@chromium.org Bug: chromium:862123, v8:5277 Change-Id: I9e8a40094f11a8b3ba6701dfa7fa026a2d052cb1 Reviewed-on: https://chromium-review.googlesource.com/1136299 Commit-Queue: 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@{#54531}
-
- 04 May, 2018 1 commit
-
-
Eric Holk (eholk) authored
In preparing for adding trap-based bounds checking to Windows, this change refactors the code to separate the platform-specific portions from that which can be shared between platforms. Internally, we've renamed `RegisterDefaultSignalHandler` to `RegisterDefaultTrapHandler` to more accurately represent the difference in terminology between Linux (signals) and Windows (exceptions). The external API is left the same so as not to break downstream clients. This CL is primarily to make room for Windows support. Future CLs will begin adding support for Windows. This is a reincarnation of https://crrev.com/c/626558. Bug: v8:6743 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaa8bfd68c14cd1d17933b12c24cb8dd5ee8a21d6 Reviewed-on: https://chromium-review.googlesource.com/998829 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by: Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#53006}
-
- 14 Apr, 2018 1 commit
-
-
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: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#52601}
-
- 04 Apr, 2018 1 commit
-
-
Eric Holk authored
The first part of this change updates StoreMem_offset_oob_i64 to use one page of Wasm memory, rather than just a few bytes. Using less than a page was out of spec for Wasm anyway, so this is better. This required a small change in the test runner to set and clear the thread_in_wasm flag around Wasm calls. This was accomplished by a ThreadInWasmScope convenience class. The majority of the changes are because the cctest environment does not support runtime exceptions. In the code generator, where we used to throw a WasmMemOutOfBounds exception, we now need to call out to the test hook instead if runtime exceptions are not supported. This involved plumbing the runtime_exception_support flag down to the code generator. Rather than adding and shuffling around extra parameters everywhere, this CL packages the previous protected instruction list in a new WasmCompilationData object that now includes the runtime_exception_support flag as well. Bug: v8:5277 Change-Id: Ic9c9e5a53a07a7773b58c0aee7c26bbd2ddf82f3 Reviewed-on: https://chromium-review.googlesource.com/989017 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52368}
-
- 26 Mar, 2018 1 commit
-
-
Michael Starzinger authored
Now that WebAssembly code has moved off the garbage collected heap, it is no longer subject to relocation and support for updating the base address for the purposes of trap handling can be removed. R=eholk@chromium.org BUG=v8:7549 Change-Id: I7a98f192e0c91274fa2ccdb59cdd106da6217948 Reviewed-on: https://chromium-review.googlesource.com/978248Reviewed-by: Eric Holk <eholk@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52207}
-
- 22 Mar, 2018 1 commit
-
-
Eric Holk authored
This CL also deprecates V8::RegisterDefaultSignalHandler. Now instead of using the old API, clients should call V8::EnableWebAssemblyTrapHandler. Just setting the --wasm-trap-handler flag will no longer have any effect. Bug: v8:5277 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Idd862185af9abcd4a3c845c02f9e916e8b56f114 Reviewed-on: https://chromium-review.googlesource.com/965005Reviewed-by: Karl Schimpf <kschimpf@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#52126}
-
- 20 Mar, 2018 1 commit
-
-
Eric Holk authored
The new API supersedes the old `RegisterDefaultSignalHandler` and flag combination. Now the embedder must explicitly call `EnableWebAssemblyTrapHandler` to activate the trap handler and optionally install the default signal handler. The old flag is now used only by D8 to decide whether to call this function. Bug: v8:5277 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I05fbb2138138bfc95b14361aabd712db84789b4a Reviewed-on: https://chromium-review.googlesource.com/963179 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52081}
-
- 02 Feb, 2018 1 commit
-
-
jgruber authored
This check verifies that all .h files in the src/ directory have an include guard of the form #ifndef V8_PATH_TO_FILE_H_ #define V8_PATH_TO_FILE_H_ // ... #endif // V8_PATH_TO_FILE_H_ The check can be skipped with a magic comment: // PRESUBMIT_INTENTIONALLY_MISSING_INCLUDE_GUARD Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0a7b96abec289ad60f64ba8418f1892a6969596d Reviewed-on: https://chromium-review.googlesource.com/897487Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51079}
-
- 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}
-
- 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 1 commit
-
-
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}
-
- 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}
-
- 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}
-