These offsets are now transported via CodeDesc.
Bug: v8:8758
Change-Id: If7485c62878bc81a55c9b4ca8ce3578dab2376ce
Reviewed-on: https://chromium-review.googlesource.com/c/1447717
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59315}
This CL revises some of our error messages to be more precise or more
aesthetically appealing.
R=titzer@chromium.org, ahaas@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: chromium:926311
Change-Id: I38eaee09fd37f9b67fdb08bc7b0df64a6eaf96f9
Reviewed-on: https://chromium-review.googlesource.com/c/1445980
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59249}
Not even when copying 0 bytes. Same for memmove and memcmp.
Bug: v8:3770
Change-Id: I3ed45a4572467ec7a9fc697ac28c004aa9b8b274
Reviewed-on: https://chromium-review.googlesource.com/c/1436217
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59101}
Anyref parameters can exist across GC runs. Therefore the GC has to
know where anyref parameters are on the stack so that it can mark them
in its marking phase, and update them in the compaction phase.
Already in a previous CL we grouped all anyref parameters so that they
can be found more easily in a stack frame, see
https://crrev.com/c/1371827. In this CL we implement the stack scanning
itself.
Note that anyref parameters are not scanned while iterating over the
caller's frame (to which they actually belong), but while iterating
over the callee's frame. The reason is that with tail-calls, only the
callee knows how many tagged stack parameters (aka anyref parameters)
there are.
R=mstarzinger@chromium.orgalso-by=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I7a41ce11d06c0d420146fdb0bb8d5606f28824d7
Reviewed-on: https://chromium-review.googlesource.com/c/1424955
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59099}
The WasmCodeManager held a list of all Isolates that use the
WasmEngine/WasmCodeManager (those two are 1:1).
Since we want to move all isolate-specific tasks (like code logging and
compilation callbacks) to the WasmEngine, this CL moves this management
from the WasmCodeManager to the WasmEngine. We now have a bidirectional
mapping from NativeModules to the Isolates that use them, and from an
Isolate to all the NativeModules it uses (n:n).
The IsolateData struct will be extended in follow-up CLs to hold things
like the ForegroundTaskRunner. The Isolate* in the NativeModule /
CompilationState will eventually be removed.
R=mstarzinger@chromium.org
Bug: v8:8689
Change-Id: Ic2c003c3949f73ce3264dd9dac96884a5c0b9896
Reviewed-on: https://chromium-review.googlesource.com/c/1433793
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59092}
Refactor the AllocateAssemblerBuffer helper for the new Assembler API.
This is the only non-mechanical part, all other callsites that create
Assembler instances can be trivially changed to the new API. This will
be done in a separate CL.
R=mstarzinger@chromium.org
Bug: v8:8689, v8:8562
Change-Id: I6c150748eeea778d9b70f41fd66fbb1221035a1b
Reviewed-on: https://chromium-review.googlesource.com/c/1415490
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58881}
This switches the experimental exception handling implementation to the
new proposal where 'catch' blocks behave in a catch-all fashion and a
new 'br_on_exn' operation is used to check for a certain exception type
and extract the exception values on a match.
R=clemensh@chromium.org
TEST=unittests/FunctionBodyDecoderTest,mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: Ib12ba28b3aa2a7d831312a83abcb00bf56d0adc3
Reviewed-on: https://chromium-review.googlesource.com/c/1409431
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58832}
We often use ResultBase or VoidResult to store or pass wasm errors
(errors with locations). This CL extracts a WasmError class which can
store an error (can also be empty), and Result<T> which stores an error
or a T (exactly one of them).
R=titzer@chromium.org
Bug: v8:8689
Change-Id: I3f5203559984a0ae8757e0130a9184957fa28df5
Reviewed-on: https://chromium-review.googlesource.com/c/1409365
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58827}
This matches the terminology that is used throughout the spec.
R=clemensh@chromium.org
Change-Id: I62445e750415e6048b805110c7306f3bdbf9da60
Reviewed-on: https://chromium-review.googlesource.com/c/1408988
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58774}
Mostly signed integer overflows, and a few cases of double
division by zero (which is defined by IEEE-754 to return
Infinity (or NaN for 0/0) but is UB in C++).
Bug: v8:3770
Change-Id: Id92725b0ac57cb357978124a3dc6f477430bc97d
Reviewed-on: https://chromium-review.googlesource.com/c/1403133
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58696}
To allow any-ref parameters, we have to make sure that any-ref stack
parameters get seen by the GC. This CL is a first step into that
direction. The goal of this CL is to group any-ref parameters at the
stack side of the parameters. This means that in the stack frame
iterator we do not need information about where anyref parameters are
in the stack frame. We only need information about how many anyref
parameters there are at the bottom of the stack frame.
R=mstarzinger@chromium.org
Also-By: mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I3ff7cc38fabed5f8e51b5b990190e35f3ea29803
Reviewed-on: https://chromium-review.googlesource.com/c/1371827
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58184}
The class declaration regexp in cpplint did not catch classes decorated
by V8_EXPORT, V8_EXPORT_PRIVATE or any other decorator containing
digits.
This will be fixed in https://github.com/google/styleguide/pull/422.
This CL already prepares the code base by fixing all errors that will
be found after that change.
Some follow-up changes were needed to fix implicit conversion that are
not taken any more now.
R=mstarzinger@chromium.org
Bug: v8:8562
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I03713bd04dbc3f54b89a6c857a93463139aa5efd
Reviewed-on: https://chromium-review.googlesource.com/c/1367751
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58143}
The existing implementation embedded an isolate-specific pointer to the
thread-in-wasm flag in the wrapper code. However, when the module code
is shared among multiple workers, this can mean that the workers
share the same thread-in-wasm flag.
With this change we load the pointer to the flag at runtime from the
current isolate. Thereby the correct flag is used even when the same
code is executed on different workers.
Note that we could access the right flag address by going through the
root register. However, changing the code generation to use the root
register requires some inconvenient steps:
* Pass the isolate to the pipeline again, which we don't want.
* Change the WasmCallDescriptor to allow the use of the root register
for wrappers but not for other code.
To avoid these issues, and allow the CL to be easy to merge back, we
got for the changes proposed here.
R=mstarzinger@chromium.org, ishell@chromium.org
Bug: v8:8533
Change-Id: If15565a7ad7cba835cfc1628e7a4d3fdef90a5c0
Reviewed-on: https://chromium-review.googlesource.com/c/1358518
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58044}
The memory.init and memory.drop instructions have a data segment index
that can only be validated by knowing the number of data segments. This
information is provided by the new DataCount section.
Bug: v8:7747
Change-Id: Ie04d57584fe028637f6e931ab53d00abc5b998a4
Reviewed-on: https://chromium-review.googlesource.com/c/1355624
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58031}
This is a reland of c2aaf0a6fa
Original change's description:
> [wasm][liftoff] Optimize one-armed ifs
>
> Do not implement one-armed ifs by emulating an empty else branch. In
> Liftoff, we can generate better code and save compile time by handling
> this specially. If the merge point at the end of the if is not reached
> by the if-branch, we do not need to generate any merge code.
>
> R=titzer@chromium.org
>
> Bug: v8:6600, v8:8423
> Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
> Reviewed-on: https://chromium-review.googlesource.com/c/1356508
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57968}
Bug: v8:6600, v8:8423
Change-Id: I6d5eea9f860486768779a33bf6bd7b87cbfc2af0
Reviewed-on: https://chromium-review.googlesource.com/c/1361040
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58024}
This reverts commit c2aaf0a6fa.
Reason for revert: Benchmarks fail, and ClusterFuzz is not happy (issue 911406, issue 911271)
Original change's description:
> [wasm][liftoff] Optimize one-armed ifs
>
> Do not implement one-armed ifs by emulating an empty else branch. In
> Liftoff, we can generate better code and save compile time by handling
> this specially. If the merge point at the end of the if is not reached
> by the if-branch, we do not need to generate any merge code.
>
> R=titzer@chromium.org
>
> Bug: v8:6600, v8:8423
> Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
> Reviewed-on: https://chromium-review.googlesource.com/c/1356508
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57968}
TBR=titzer@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6600, v8:8423
Change-Id: I5cb3b069f40e34f34da4013e666f6ff293752567
Reviewed-on: https://chromium-review.googlesource.com/c/1360633
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58012}
Do not implement one-armed ifs by emulating an empty else branch. In
Liftoff, we can generate better code and save compile time by handling
this specially. If the merge point at the end of the if is not reached
by the if-branch, we do not need to generate any merge code.
R=titzer@chromium.org
Bug: v8:6600, v8:8423
Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
Reviewed-on: https://chromium-review.googlesource.com/c/1356508
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57968}
The placement of the exceptipon section is by now restricted to be in
between the Global and the Import section. This changes our validation
to check this stricter requirement now.
R=clemensh@chromium.org
TEST=unittests/WasmModuleVerifyTest
BUG=v8:8091
Change-Id: Ib3ea625fd4df93bffda47ced09e6969159f7ac70
Reviewed-on: https://chromium-review.googlesource.com/c/1356504
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57962}
The bulk-memory proposal adds a new DataCount section that declares the
number of data segments that are expected to be seen in the Data
section. This is similar to the way the number of functions is split
between the Function and Code sections.
The DataCount section occurs before the Code section, so we can do
single-pass validation of the new `memory.init` and `memory.drop`
instructions, which have data segment indices as immediates.
Bug: v8:7747
Change-Id: Ibc5a7ee9336dbc5d0fd667572c42cb065c048e00
Reviewed-on: https://chromium-review.googlesource.com/c/1352792
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57951}
Make sure to check that the number of declared functions (specified in the
function section) matches the number of function bodies, even if the code
section is omitted.
Note that it is valid to have a function section with zero declared functions
and an omitted code section, and vice versa.
Bug: v8:8514
Change-Id: I4effa5abe2ed6d71146a665d2df6a2f48b5a84be
Reviewed-on: https://chromium-review.googlesource.com/c/1351306
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57949}
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/1351024
Reviewed-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}
The MemoryInitImmediate and TableInitImmediate read a Memory/Table
index, followed by a segment index. If reading the first index fails, we
need to stop reading, or the decoder will read past the end.
Bug: chromium:907324
Change-Id: I3eb46c08d03e3b2e44ed4081d307b32c799abcec
Reviewed-on: https://chromium-review.googlesource.com/c/1351502
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57889}
This reverts commit 4644b32e02.
Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
Original change's description:
> [wasm] Add more unit tests for trap handler
>
> The unittests test if the trap handler only handles those traps it
> is supposed to handle:
> * Only handle traps when the thread-in-wasm flag is set.
> * Only handle traps of the right type, i.e. memory access violations.
> * Only handle traps at recorded instructions.
>
> The tests also test the consistency of the thread-in-wasm flag. I made
> one change in the trap handler where that consistency could be
> violated.
>
> All tests are executed with the default trap handler provided by V8,
> and with the trap handler callback installed in a test signal/exception
> handler.
>
> Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
> Reviewed-on: https://chromium-review.googlesource.com/c/1340246
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57858}
TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1351021
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57861}
The unittests test if the trap handler only handles those traps it
is supposed to handle:
* Only handle traps when the thread-in-wasm flag is set.
* Only handle traps of the right type, i.e. memory access violations.
* Only handle traps at recorded instructions.
The tests also test the consistency of the thread-in-wasm flag. I made
one change in the trap handler where that consistency could be
violated.
All tests are executed with the default trap handler provided by V8,
and with the trap handler callback installed in a test signal/exception
handler.
Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
Reviewed-on: https://chromium-review.googlesource.com/c/1340246
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57858}
These instructions aren't implemented yet in TF or in Liftoff, but they
are properly decoded.
The table instructions (i.e. `table.{init,drop,copy}`) are validated,
since the table and element sections occur before the code section. The
memory instructions (i.e. `memory.{init,drop,copy,fill}`) are not
validated because the data section occurs after the code section, so it
can't be verified in one pass (without throwing a validation error
later).
There is currently a discussion about whether to add a new section
(similar to `func`) that predefines the number of expected data
segments. If we add this, then we can validate in one pass. For now,
we'll leave it unimplemented.
Bug: v8:7747
Change-Id: I839edf51721105a47a1fa8dd5e5e1bd855e72447
Reviewed-on: https://chromium-review.googlesource.com/c/1339241
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57622}
This avoids creating an on-heap copy for import wrappers by directly
adding the {WasmCode} into the native heap instead. It reduces
compilation time as well as useless GC pressure.
R=clemensh@chromium.org
BUG=v8:8423
Change-Id: Ia063523834c963591027c7d1ed78b795d24907bf
Reviewed-on: https://chromium-review.googlesource.com/c/1335566
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57511}
See the WebAssembly bulk memory proposal here:
https://github.com/WebAssembly/bulk-memory-operations
This initial CL adds a wasm experimental flag:
`--experimental-wasm-bulk-memory`, and also parsing of passive segments.
A passive segment is one that is not copied into the table/memory on
instantiation, but instead later via the `{table,memory}.init`
instructions.
The binary format of passive data segments is unlikely to change, but
the format for passive element segments may change (see
https://github.com/WebAssembly/bulk-memory-operations/pull/39).
Bug: v8:7747
Change-Id: I2a7fb9bc7648a722a8c4aab4185c68d3d0843858
Reviewed-on: https://chromium-review.googlesource.com/c/1330015
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57451}
After the first decoder error, the streaming processor should not be
called again. To enforce this, reset the {processor_} field. This also
makes the {ok_} field redundant.
Note that this refactoring is also necessary for a future CL which
makes the {StreamingProcessor} keep the {AsyncCompileJob} alive. By
resetting the processor, we also remove that link.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: I42f5ed26a8f26c3dc8db5676557a0d82021e132e
Reviewed-on: https://chromium-review.googlesource.com/c/1329179
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57435}
Compilation units currently contain pointers into allocated space that
contains the code of the respective function. This requires us to keep
the StreamingDecoder alive as long as compilation is still running
(including tiering).
This CL refactors this by having an additional redirection
(WireBytesStorage) which can point to either the StreamingDecoder or
the NativeModule. We only keep the code section buffer alive as long as
the StreamingWireBytesStorage is still in use.
I will further refactor memory ownership in a follow-up CL to not make
the AsyncCompileJob keep the StreamingDecoder alive.
R=ahaas@chromium.org
Bug: v8:8343,v8:7921,v8:8050
Change-Id: I780582c3217abf64000454f2c9c108b9ac9fbff1
Reviewed-on: https://chromium-review.googlesource.com/c/1319588
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57317}
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}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
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}
The {CompilationState} currently stores the {WasmEngine}, while the
{NativeModule} only stores the {WasmCodeManager}. From a high-level
view, this does not make much sense. The {NativeModule} belongs to
exactly one {WasmEngine}, so that link should be stored there. We can
then get to the {WasmCodeManager} from the {WasmEngine}.
This change requires a refactoring of the {WasmCodeManagerTest} which
created {WasmCodeManager}s independent of the {Isolate} and the
{WasmEngine}. This is not supported any more.
Note that in production, each {WasmEngine} owns exactly one
{WasmCodeManager} and one {WasmMemoryTracker}, so testing that a
{WasmMemoryTracker} can be shared by several {WasmCodeManager}s didn't
make sense in the first place.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I582e698be35f97dbd38bf6e12eb7f8ee4fc1f0f2
Reviewed-on: https://chromium-review.googlesource.com/c/1297960
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56992}
Instead, create it when needed and pass it down to the actual
compilation.
This saves memory by making the WasmCompilationUnit smaller and will
eventually allow us to implement the trap handler fallback correctly by
using an updated ModuleEnv in background compilation and tier up.
R=mstarzinger@chromium.org
Bug: v8:5277, v8:8343
Change-Id: I0dc3a37fb88e54eb4822dc99d58ff024f4b2a367
Reviewed-on: https://chromium-review.googlesource.com/c/1293953
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56896}
This adds an attribute field to the binary encoding of exception types
in the exceptions and import section. Currently the attribute value is
not used and expected to be zero, but it ensures the binary encoding is
extensible for future changes.
R=clemensh@chromium.org
TEST=unittests/WasmModuleVerifyTest
BUG=v8:8153
Change-Id: I6f0e10cb1b6515177d8200ebf1f4f0b122832868
Reviewed-on: https://chromium-review.googlesource.com/c/1291075
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56841}
Previously, this was just a field on the WasmResult, which is not
allowed according to the style guide.
A special r-value accessor for the value is needed for the cases where
the contained type is not copyable, e.g. unique_ptr.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: Ia3c14c4c62c3c2e07f1dc4594f1bc9d1da88f91e
Reviewed-on: https://chromium-review.googlesource.com/c/1290974
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56823}
This is cleanups that I forgot to include in the previous CLs or that
did not fit in any of them.
This is the eighth CL in a series to improve our module decoder tests
and make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: I0db04288f1efd9bb4642478d22c0edc8ac17e024
Reviewed-on: https://chromium-review.googlesource.com/c/1286669
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56738}
This is the seventh CL in a series to improve our module decoder tests
and make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: Ib8bd2cc3f2fdb23b39511657a4af99f6fa781172
Reviewed-on: https://chromium-review.googlesource.com/c/1286346
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56737}
Currently, the empty function bodies actually contain the byte 0, which
is the unreachable opcode. This CL fixes this to be empty function
bodies, and uses the macros more consistently.
This is the sixth CL in a series to improve our module decoder tests and
make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: I5f029210b4589797ee194e4082afec2c7bc31561
Reviewed-on: https://chromium-review.googlesource.com/c/1286343
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56736}
Compute the length of more fields automatically, in particular names.
This is the fifth CL in a series to improve our module decoder tests and
make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: I1bd27f45380d82af2d7319f15ac7e37d5b9e4081
Reviewed-on: https://chromium-review.googlesource.com/c/1283077
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56721}
Instead of specifying the byte length of a section manually, just
compute it automatically from the bytes given. Manual computation is
particularly difficult because of the macros involved, which can expand
to several bytes.
This is not a pure refactoring, it also fixes several occasions where
we calculated the length wrong.
Drive-by: Add some ENTRY_COUNT macro uses.
This is the fourth CL in a series to improve our module decoder tests and
make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: I0d2ceb751fc8e5625ffdf4189d4b5253aecc2541
Reviewed-on: https://chromium-review.googlesource.com/c/1283075
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56718}
Function declarations reference a previously defined or imported
signature. Make this visible when declaring empty functions.
Also rename IMPORT_SIG_INDEX to SIG_INDEX since it can also reference a
locally defined signature.
This is the third CL in a series to improve our module decoder tests and
make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: Ibfd9ea39ea35bacdb453602f8985fb3306455de4
Reviewed-on: https://chromium-review.googlesource.com/c/1282958
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56714}
Ensure that {min} is smaller than {max}, and auto-compute {max} as
{arraysize(data)}.
We had two tests which did not actually test anything.
This is the second CL in a series to improve our module decoder tests
and make them more readable.
R=titzer@chromium.org
Bug: v8:8238
Change-Id: Ie467fa54609bc5fd860608085a2d58ed8341f5e7
Reviewed-on: https://chromium-review.googlesource.com/c/1282956
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56703}
