Commit Graph

24 Commits

Author SHA1 Message Date
Clemens Hammacher
0738f0f668 [wasm] Move "thread in wasm" flag handling out of compiled code
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/712597
Reviewed-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}
2017-10-16 15:17:29 +00:00
Eric Holk (eholk)
1117da834c Reland "Reland "[wasm] trap handlers: fall back on old signal handler""
This is a reland of cc237d872b
Original change's description:
> Reland "[wasm] trap handlers: fall back on old signal handler"
> 
> This is a reland of ee4fe8963c
> 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/713956
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48474}
2017-10-11 20:49:45 +00:00
Michael Achenbach
33d4e2096f Revert "Reland "[wasm] trap handlers: fall back on old signal handler""
This reverts commit cc237d872b.

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 ee4fe8963c
> 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/711854
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48436}
2017-10-11 06:25:43 +00:00
Eric Holk
cc237d872b Reland "[wasm] trap handlers: fall back on old signal handler"
This is a reland of ee4fe8963c
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}
2017-10-11 02:03:17 +00:00
Eric Holk
0a97c51f35 Revert "[wasm] trap handlers: fall back on old signal handler"
This reverts commit ee4fe8963c.

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/710034
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48430}
2017-10-10 18:11:25 +00:00
Eric Holk
ee4fe8963c [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}
2017-10-10 18:03:12 +00:00
Clemens Hammacher
af85c865ba [wasm] Reduce size of ProtectedInstructionData
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}
2017-09-27 19:26:23 +00:00
Eric Holk (eholk)
46f6e24a41 [wasm] trap handlers: Factor out landing pad search code
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/644104
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48191}
2017-09-27 19:01:01 +00:00
Eric Holk
f180d9fb59 [wasm] check trap handler consistency in debug builds; simplify structures
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}
2017-09-27 16:24:14 +00:00
Eric Holk
c7b3fddcbb [wasm] do not register trap handler data for previously registered code
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}
2017-09-25 16:44:57 +00:00
Eric Holk
5b127a9796 [wasm] Track and expose number of recovered Wasm faults
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}
2017-09-19 04:10:20 +00:00
Ben Noordhuis
e020aae394 [wasm] Work around glibc thread-local storage bug
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}
2017-08-17 13:28:14 +00:00
Eric Holk
f315b32267 Add eholk to Wasm-related OWNERS files
Bug: 
Change-Id: I1ab93d5b2d02d9a4851c2e67d33968a7cafaedd3
Reviewed-on: https://chromium-review.googlesource.com/610892
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47294}
2017-08-10 18:58:00 +00:00
Jochen Eisinger
e9de55d595 Remove myself from non-toplevel owners files
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/551899
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46275}
2017-06-28 10:00:48 +00:00
Jochen Eisinger
536a5cd2a9 Add COMPONENT tags to OWNERS files where appropriate
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}
2017-05-22 10:15:28 +00:00
Eric Holk
b7e9428735 [wasm] clear and set thread-in-wasm flag on runtime calls
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}
2017-03-27 22:29:15 +00:00
Eric Holk
3a5262ec08 Fix Android x64 build
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}
2017-03-15 00:28:41 +00:00
eholk
118c376fcb [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-Original-Commit-Position: refs/heads/master@{#43523}
Committed: a5af7fe9ee
Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Commit-Position: refs/heads/master@{#43755}
Committed: 338622d7ca
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43759}
2017-03-13 22:12:23 +00:00
eholk
aba151b92f 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: a5af7fe9ee
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43755}
> Committed: 338622d7ca

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}
2017-03-13 20:03:25 +00:00
eholk
338622d7ca [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: a5af7fe9ee
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43755}
2017-03-13 19:14:35 +00:00
bmeurer
0b3e554e03 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: a5af7fe9ee

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}
2017-03-01 19:47:27 +00:00
eholk
a5af7fe9ee [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}
2017-03-01 18:02:13 +00:00
eholk
91f8a063cc [wasm] Move protected instruction info to RelocInfo
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}
2017-01-31 02:25:57 +00:00
eholk
bf35d15e52 [wasm] OOB traps: build protected instruction list during codegen
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}
2016-11-30 22:32:03 +00:00