- 22 Mar, 2017 1 commit
-
-
daniel.bevenius authored
Currently there are a number of comment in src/v8.h which look like this: TODO(dcarney): mark V8_WARN_UNUSED_RESULT. This commit attempts to remove these comments and add the V8_WARN_UNUSED_RESULT macro to the methods in question. BUG= Review-Url: https://codereview.chromium.org/2135973002 Cr-Commit-Position: refs/heads/master@{#44010}
-
- 20 Mar, 2017 2 commits
-
-
Clemens Hammacher authored
Before, we were redirecting each function to the interpreter by iterating all code and patching all call sites using this one function. The runtime was hence quadratic if all functions were redirected to the interpreter as done by the --wasm-interpret-all flag. This CL fixes this to only iterate the code once and redirecting an arbitrary number of function. R=ahaas@chromium.org, titzer@chromium.org BUG=v8:5822 Change-Id: Ia4f2e94a2468f9bef3035b599e1f8a18acf309da Reviewed-on: https://chromium-review.googlesource.com/455785 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43946}
-
Clemens Hammacher authored
This CL adds general lazy compilation support to WebAssembly, according to the design described in the design doc (see referenced bug). It's not used currently, but I tested locally that all tests succeed if I enable it by default. With a later CL, we will enable lazy compilation by default for validate-asm: https://chromium-review.googlesource.com/451318 R=titzer@chromium.org, ahaas@chromium.org, bmeurer@chromium.org BUG=v8:5991 Change-Id: I85440382118a24fc245e78a5a90cf2b95659cd69 Reviewed-on: https://chromium-review.googlesource.com/451317 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43936}
-
- 17 Mar, 2017 3 commits
-
-
titzer authored
This CL renames all occurrences of "internal field" to "embedder field" to prevent confusion. As it turns out, these fields are not internal to V8, but are actually embedder provided fields that should not be mucked with by the internal implementation of V8. Note that WASM does use these fields, and it should not. BUG=v8:6058 Review-Url: https://codereview.chromium.org/2741683004 Cr-Commit-Position: refs/heads/master@{#43900}
-
neis authored
This is a first step towards moving Turbofan code generation off the main thread. Summary of the changes: - AssemblerBase no longer has a pointer to the isolate. Instead, its constructor receives the few things that it needs from the isolate (on most architectures this is just the serializer_enabled flag). - RelocInfo no longer has a pointer to the isolate. Instead, the functions that need it take it as an argument. (There are currently still a few that implicitly access the isolate through a HeapObject.) - The MacroAssembler now explicitly holds a pointer to the isolate (before, it used to get it from the Assembler). - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since it's not used at all in the Assemblers. - A few architectures implemented parts of the Assembler with the help of a Codepatcher that is based on MacroAssembler. Since the Assembler no longer has the isolate, but the MacroAssembler still needs it, this doesn't work anymore. Instead, these Assemblers now use a new PatchingAssembler. BUG=v8:6048 Review-Url: https://codereview.chromium.org/2732273003 Cr-Commit-Position: refs/heads/master@{#43890}
-
gdeepti authored
DetachArrayBuffer makes incorrect assumptions about the state of the ArrayBuffer. It assumes that that the ArrayBuffer is internal to wasm unless guard pages are enabled, this is not the case as the ArrayBuffer can be externalized outside of wasm, in this case through gin. BUG=chromium:700384 Review-Url: https://codereview.chromium.org/2754153002 Cr-Commit-Position: refs/heads/master@{#43880}
-
- 15 Mar, 2017 1 commit
-
-
Eric Holk authored
Change-Id: I47f0d5578a7c26aa7a30c97175eefc1a9c935d77 Reviewed-on: https://chromium-review.googlesource.com/455318 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@{#43808}
-
- 14 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
If this flag is set, all code will be executed in the interpreter. At some point in the future we might want to have a variant for testing all code with this flag. Currently, I am using it for finding unimplemented functionality in the interpreter and testing existing functionality. Mjsunit tests in follow-up CLs will use this flag too. R=ahaas@chromium.org, titzer@chromium.org BUG=v8:5822 Change-Id: I1393b4aedbb9f9070e011362ec95cb89f296dab4 Reviewed-on: https://chromium-review.googlesource.com/453700 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#43773}
-
- 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}
-
- 06 Mar, 2017 2 commits
-
-
Clemens Hammacher authored
From asm.js code we might get an empty ArrayBuffer as heap memory. In this case, both the old memory start and the new memory start will be nullptr. The size however has to be patched from default_size to 0. This CL changes code specialization to be able to either patch memory references, or patch memory sizes or both. R=titzer@chromium.org, ahaas@chromium.org BUG=chromium:698587 Change-Id: I4d9d811d75cb83842f23df317e8e7fc02aeb5146 Reviewed-on: https://chromium-review.googlesource.com/450257 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43613}
-
clemensh authored
The previous fix (http://crrev.com/2720813002) was problematic for functions containing i64 parameters or returns. Those would throw a TypeError when called via WASM_TO_JS and JS_TO_WASM. Instead, we now unwrap the WASM_INTERPRETER_ENTRY function and call it directly. This removes the option to later redirect back to the original wasm function, but this functionality is not needed currently. Plus drive-by fix to put functions in anonymous namespace in wasm-compiler.cc. R=ahaas@chromium.org, titzer@chromium.org BUG=v8:5971, v8:5822 Review-Url: https://codereview.chromium.org/2725333002 Cr-Commit-Position: refs/heads/master@{#43603}
-
- 03 Mar, 2017 2 commits
-
-
clemensh authored
If the imported wasm function is being debugged (i.e. redirects to the interpreter), call it via the JS_TO_WASM stub, such that we can disable the breakpoint later by patching the exported function. This also contains a drive-by fix in wasm-translation.cc (for the case that all known positions are bigger than the requested one). R=titzer@chromium.org, kozyatinskiy@chromium.org BUG=v8:5971, v8:5822 Review-Url: https://codereview.chromium.org/2720813002 Cr-Commit-Position: refs/heads/master@{#43583}
-
clemensh authored
In lazy compilation, we only compile one function at a time, and we might not have the wire bytes of the whole module available. This CL prepares the WasmCompilationUnit for this setting. It will also be helpful for streaming compilation. Also, the ErrorThrower (which might heap-allocate) is not stored in the WasmCompilationUnit any more. Instead, it is passed to the FinishCompilation method which is allowed to heap-allocate. R=titzer@chromium.org, ahaas@chromium.org BUG=v8:5991 Review-Url: https://codereview.chromium.org/2726553003 Cr-Commit-Position: refs/heads/master@{#43573}
-
- 02 Mar, 2017 2 commits
-
-
clemensh authored
Most are minor performance optimizations that aggregated while implementing other changes. Those fixes will probably not be visible in perf graphs, but they bothered me anyway. R=titzer@chromium.org, ahaas@chromium.org Review-Url: https://codereview.chromium.org/2714373003 Cr-Commit-Position: refs/heads/master@{#43535}
-
clemensh authored
This is a minor performance optimization. Instead of iterating the relocation information till the end, we exit the loop once we found the call to wasm code. R=titzer@chromium.org, ahaas@chromium.org Review-Url: https://codereview.chromium.org/2717973003 Cr-Commit-Position: refs/heads/master@{#43534}
-
- 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}
-
- 27 Feb, 2017 1 commit
-
-
clemensh authored
Skip parallel compilation if less than two functions need to be compiled, and skip over imported functions instead of adding nullptrs for them to the compilation_units_ vector. R=titzer@chromium.org, ahaas@chromium.org Review-Url: https://codereview.chromium.org/2718053002 Cr-Commit-Position: refs/heads/master@{#43449}
-
- 24 Feb, 2017 1 commit
-
-
titzer authored
This is a refactoring CL in preparation for implementing asynchronous compilation. It moves all the compilation-related functionality to a helper class which will make it easier to split into background and foreground tasks which is needed for concurrent/synchronous execution of compilation. R=clemensh@chromium.org,ahaas@chromium.org BUG=v8:6003 Review-Url: https://codereview.chromium.org/2710603006 Cr-Commit-Position: refs/heads/master@{#43413}
-
- 20 Feb, 2017 4 commits
-
-
titzer authored
R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2703243002 Cr-Commit-Position: refs/heads/master@{#43332}
-
clemensh authored
All patching logic is now bundled in one compilation unit. The CodeSpecialization object is set up by all relocation and patching that should be applied, and then be run on individual code objects or the whole instance in one go. We hence only need to iterate all relocation tables exactly once at instantiation. Also, we do not patch contexts any more since we do not embed them in generated code any more. R=titzer@chromium.org BUG=v8:5991 Review-Url: https://codereview.chromium.org/2696143006 Cr-Commit-Position: refs/heads/master@{#43324}
-
clemensh authored
The generated code for JSToWasm wrappers only depends on the signature of the exported function. Hence, we can reuse the generated code and just patch the reference to the called wasm code. For the unity-wasm benchmark, we reach a hit rate of 98.07% for this cache, and only 395 instead of 20471 wrappers are compiled. This brings down instantiation time from 2.9s to 1.6s on a MBP. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2705993002 Cr-Commit-Position: refs/heads/master@{#43322}
-
titzer authored
This makes it easier to implement asynchronous compilation by hiding all the implementation details of both synchronous and asynchronous compilation within wasm-module.cc, whereas before the code in wasm-js.cc actually implemented asynchronous compilation in terms of synchronous. BUG= Review-Url: https://codereview.chromium.org/2695813005 Cr-Commit-Position: refs/heads/master@{#43310}
-
- 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 Jan, 2017 1 commit
-
-
gdeepti authored
When WebAssembly.Table initial size is greater than the declared initial size, table size references should be updated on instantiate for functions to be called at indices greater than the declared initial size. R=bradnelson@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2661773002 Cr-Commit-Position: refs/heads/master@{#42781}
-
- 28 Jan, 2017 1 commit
-
-
bradnelson authored
Return a regular JSObject in the asm.js -> wasm case. BUG=v8:5877 R=mtrofin@chromium.org,aseemgarg@chromium.org,titzer@chromium.org Review-Url: https://codereview.chromium.org/2664493002 Cr-Commit-Position: refs/heads/master@{#42757}
-
- 26 Jan, 2017 1 commit
-
-
gdeepti authored
Memory.Grow should detach the ArrayBuffer associated with the Mem object after Grow. Currently, when guard pages are enabled protection is changed to make more of the buffer accessible. This does not work for when the buffer should be detached after grow, because the memory object has a reference to the same buffer befor/after grow. R=titzer@chromium.org, eholk@chromium.org Review-Url: https://codereview.chromium.org/2653183003 Cr-Commit-Position: refs/heads/master@{#42717}
-
- 24 Jan, 2017 6 commits
-
-
mtrofin authored
BUG=v8:5885 Review-Url: https://codereview.chromium.org/2649163004 Cr-Commit-Position: refs/heads/master@{#42636}
-
titzer authored
R=ahaas@chromium.org,rossberg@chromium.org BUG=chromium:575167 Review-Url: https://codereview.chromium.org/2626263004 Cr-Commit-Position: refs/heads/master@{#42634}
-
ahaas authored
Similar to the maximum memory size this limit caused problems for the fuzzer due to oom issues. With the command line flag we can limit the maximum table size for the fuzzer. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2648223004 Cr-Commit-Position: refs/heads/master@{#42623}
-
titzer authored
BUG=v8:5860 R=rossberg@chromium.org Review-Url: https://codereview.chromium.org/2653533003 Cr-Commit-Position: refs/heads/master@{#42622}
-
mtrofin authored
Chromium coding standard (https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md#Multiple-inheritance) In this case, a structure associating the 2 values is sufficient. BUG= Review-Url: https://codereview.chromium.org/2651903002 Cr-Commit-Position: refs/heads/master@{#42618}
-
bradnelson authored
A recent change to disallow wasm compilation in contexts where CSP unsafe-eval would disallow eval also ended up banning asm.js there: https://codereview.chromium.org/2646713002 This ends up banning non-evaled asm.js even in some places it should be allowed. NOTE: Although asm.js code converted to wasm generates an intermediate wasm module. asm.js code evaled in a disallowed context can't even get that far (as it's stoped at the eval site). BUG=683867 R=mtrofin@chromium.org,titzer@chromium.org,adamk@chromium.org Review-Url: https://codereview.chromium.org/2656463004 Cr-Commit-Position: refs/heads/master@{#42616}
-
- 23 Jan, 2017 2 commits
-
-
rossberg authored
Also fixes check for table segments to be performed against actual size not declared one. Makes us pass memory.wast and linking.wast tests (modulo issue 5860). R=titzer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2649553002 Cr-Commit-Position: refs/heads/master@{#42607}
-
ahaas authored
The hardcoded constant caused a problem for the wasm fuzzer because when the maximum memory was allocated in a test case, clusterfuzz ran out of memory. with the command line flag we can set a lower limit for the fuzzer. The flag has the value of the constant as its default value, so that for everything but the fuzzers nothing should change. R=titzer@chromium.org BUG=chromium:676888 Review-Url: https://codereview.chromium.org/2626313003 Cr-Commit-Position: refs/heads/master@{#42599}
-
- 20 Jan, 2017 2 commits
-
-
gdeepti authored
BUG=v8:5863 R=titzer@chromium.org, dschuff@chromium.org Review-Url: https://codereview.chromium.org/2640403004 Cr-Commit-Position: refs/heads/master@{#42578}
-
clemensh authored
Frame inspection is currently limited to locations of execution. Further details like local variables or stack content will follow later. The FrameInspector now stores a pointer to the interpreted wasm frame, and redirects certain requests there, just as for deoptimized frames. Hitting breakpoints is now also supported for wasm frames. R=yangguo@chromium.org, titzer@chromium.org BUG=v8:5822 Review-Url: https://codereview.chromium.org/2629823003 Cr-Commit-Position: refs/heads/master@{#42551}
-
- 19 Jan, 2017 1 commit
-
-
mtrofin authored
Make wasm code generation (including deserialization) aware of allow_codegen_callback - if one were set by the host - akin to what we do for `eval`. This allows web pages that opt out of unsafe-eval to also opt out of wasm scenarios. BUG=v8:5869 Review-Url: https://codereview.chromium.org/2646713002 Cr-Commit-Position: refs/heads/master@{#42519}
-