- 20 Apr, 2020 1 commit
-
-
Zhao Jiazhong authored
Port 1d8f1376 https://crrev.com/c/2154048 Change-Id: I7237e784d86cd78e936741a47887c2efe731cbbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2156165Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#67221}
-
- 18 Apr, 2020 1 commit
-
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I95262d0ab550d41b7c5e2ce4eb9ec8164c53e892 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154048Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/master@{#67218}
-
- 17 Apr, 2020 13 commits
-
-
Ng Zhi An authored
Bug: chromium:1071711 Bug: v8:10258 Change-Id: Id19add0c7e77ee3b834ff47274b9986cc2aa1f69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154767Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67216}
-
Jakob Kummerow authored
And a new flag --experimental-wasm-gc, which doesn't do anything yet. Bug: v8:7748 Change-Id: I927d1d90559249db3ee9f8d240775d45098e52a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154197 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67215}
-
Clemens Backes authored
{StaticCharVector}, according to its name, should return a {Vector<const char>}. For getting a {Vector<const uint8_t>}, the method should be called {StaticOneByteVector}, analog to the {OneByteVector} methods that already exist. Also, {StaticCharVector} is constexpr, but {StaticOneByteVector} cannot be, since it contains a {reinterpret_cast}. The same holds for {Vector::cast} in general. This CL - changes the return type of {StaticCharVector} to be {Vector<const char>}, - introduces a new {StaticOneByteVector} which returns {Vector<const uint8_t>}, - fixes constexpr annotations at various methods returning {Vector}s, - refactors users of {StaticCharVector} to either use {StaticOneByteVector} instead, or work on {char} if that makes more sense. R=leszeks@chromium.org Bug: v8:10426 Change-Id: I71e336097e41ad30f982aa6344ca3d67b3a01fe3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154196 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67213}
-
Milad Farazmand authored
Port fc29c453 Port 8ef2f799 R=zhiguo.zhou@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: If84d63be9864ab2ff10b522018ecbac0c56b2bea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154765Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67209}
-
Jakob Kummerow authored
These opcodes are not officially specified yet, they are defined in the "prototype implementation spec" at https://bit.ly/3cWcm6Q. Drive-by: drop a unit test whose entire coverage can be provided by a compile-time check. Bug: v8:7748 Change-Id: Icefa6dd321802c8a01c4561178b9d21eca1fbaa3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152841Reviewed-by:
-
Clemens Backes authored
This adds another enum value in the {ForDebugging} enum for stepping code. By not adding the code to the code table and jump table, we will never execute this code via a wasm function call. The code will only be used for the one frame where we want to step through. This speeds up stepping over recursive calls enormously, since the recursive calls don't run into the flooded breakpoints any more. It also fixes issues with non-local control flow, i.e. catching a trap and reentering the same wasm function. R=thibaudm@chromium.org Bug: v8:10235 Change-Id: Idb304dd465418f842016a20c21d68989bb78cf1d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153205 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67205}
-
Clemens Backes authored
Stepping only happens in one frame at a time, so we don't need to rewrite the whole stack. This allows us to remove the {flooded_function_index_}, since no function is globally flooded any more. A follow-up CL will ensure that the code will also not be installed in the code table and jump table any more, to fix issues with non-local control flow (i.e. catching a trap and reentering wasm), where we could currently accidentally execute flooded code. It will also speed up stepping over recursive calls enormously, since the recursive calls don't run into the flooded breakpoints any more. R=thibaudm@chromium.org Bug: v8:10235 Change-Id: Ifae5e35c3242c95e1fe1a89a169ce874b818a288 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152646Reviewed-by: -
Paolo Severini authored
This changelist adds to the GDB stub (in class wasm::gdb_server::Target) the logic to decode and execute GDB-remote commands and to format response packets to be sent back to the debugger. Here most of the commands still act as a NOOP; the actual implementation requires interactions with the Wasm engine and will be implemented in the next CL of this series. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Bug: chromium:1010467 Change-Id: Icfa63be9e1eaa657c05876d0d4e86927e0885b90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938466 Commit-Queue: Paolo Severini <paolosev@microsoft.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
Port 8ef2f799 https://crrev.com/c/2150157 Change-Id: I70ffb8e0c669398339eb6e794bef2b7920b58cd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153194Reviewed-by:
-
Paolo Severini authored
This changelist adds the logic to format, decode, sends and receive packets in the format specified by the GDB-remote protocol (https://sourceware.org/gdb/onlinedocs/gdb/Overview.html#Overview). Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Bug: chromium:1010467 Change-Id: Ibc9c6713c561d06847b472fab591c208c193199f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929409 Commit-Queue: Paolo Severini <paolosev@microsoft.com> Reviewed-by:
-
Zhao Jiazhong authored
Port fc29c453 https://crrev.com/c/2148640 Change-Id: I75092072ac6961c26559bd69d6a8413d2e9d2689 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153189Reviewed-by:
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: Ic71a2a012cbd538d65afb047fe73e98be6454aed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150157 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by:
-
Zhou, Zhiguo authored
Bug: v8:9909 Change-Id: I1ec888ce0b3389afcb0edd1033bef179327e140c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148640Reviewed-by:
-
- 16 Apr, 2020 9 commits
-
-
Ng Zhi An authored
SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We were decoding this incorrectly as a fixed uint8. This fixes the decoder to properly handle multi bytes. In some cases, the multi byte logic is applied to all prefixed opcodes. This is not a problem, since for values < 0x80, the LEB encoding is a single byte, and decodes to the same int. If the prefix opcode has instructions with index >= 0x80, it would be required to be LEB128 encoded anyway. There are a bunch of trivial changes to test-run-wasm-simd, to change the macro from BUILD to BUILD_V, the former only works for single byte opcodes, the latter is a new template-based macro that correct handles multi-byte opcodes. The only unchanged test is the shuffle fuzzer test, which builds its own sequence of bytes without using the BUILD macro. Bug: v8:10258 Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: Ia5038fccb756d79b08b10a5fd0664b0da8b6a8ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151172Reviewed-by:
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: Ib94db390f70ddaa7eafb5af77023b1024c2b96b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151168Reviewed-by:
-
Philip Pfaffe authored
This CL relands the implementation of the __getLocal and __sbrk APIs of the evaluator interface reverted in efea7407. Update the original commit to account for a changes to the import function name tracking and defaulting to debugging with liftoff. Change-Id: I9674aad419fb1dab0a9ecbb5d3fd4c33186b127a Bug: chromium:1020120 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151353 Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67178}
-
Clemens Backes authored
This cleans up several parts of the tiering logic. 1) Instead of using the {ExecutionTier} to specify whether we do tier up or down, we introduce a new {TieringState} enum and use that consistently (also where a {bool} was used before). 2) When tiering up or tiering down, always recompile all functions. It's very unlikely that we can reuse previous code anyway (tiering down is cheap enough to just always do it, and when tiering up we need to recompile everything anyway). 3) Remove the {WasmEngine::RecompileAllFunctions} method and inline the implementation into callers. 4) Drive-by: Remove some obsolete comments and fix or extend others. R=thibaudm@chromium.org Bug: v8:10410 Change-Id: Ic765c6760dd97473ccfd469f22a2514695075587 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151355Reviewed-by: -
Andreas Haas authored
The existing interface assumed that for atomic binop instructions, the value register and the result register are the same. However, for x64, this assumption is not always useful, and for platforms like arm, this assumption is even negative. The existing interface was originally introduced because ia32 lacks registers, and we wanted to avoid platform-specific code in liftoff-compiler.cc. However, by now the lack of registers on ia32 required us to use platform-specific code also in other places, so we can also use it for atomic binops and thereby enable a better code generation. R=clemensb@chromium.org Bug: v8:10108 Change-Id: If39cc5f49934422b632bb2a5793c7f5d5d2b65c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150585Reviewed-by:
-
Philip Pfaffe authored
Trying to write an empty byte array currently invokes undefined behavior if the byte array is null. That's the case when trying to write an empty vector for example. Copying zero bytes from nullptr is defined as UB for memcpy. Change-Id: I6f7e920c1e19e8b2e3779bbc1c0ad79fc8bd6e98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148789 Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit https://crrev.com/c/2144966, which was merged to v8.1 in https://crrev.com/c/2151345. R=thibaudm@chromium.org Bug: chromium:1070199 Change-Id: Idb25cfaa52f7f7aa07353cf0372e6758adb58d78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151346Reviewed-by:
-
Zhao Jiazhong authored
Port ad55fa63 https://crrev.com/c/2147148 Change-Id: I5375ae4bddb2221c6f7860e55111c95beeed757d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152069Reviewed-by:
-
- 15 Apr, 2020 9 commits
-
-
Kim-Anh Tran authored
Bug: chromium:1043034 Change-Id: I18b1c307ab198e7fbd4d5bc7df399c310f317c4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149419Reviewed-by:
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: I8beaa9a430c86c00311e5cc713c2870d2a588ab8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149712Reviewed-by:
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: I6e367b98c0f85c740947d72e9b0a29870e9e03e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147602Reviewed-by:
-
Milad Farazmand authored
Port 325e3290 R=jing.bao@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I743d710a501e1f01cbe4c4052fb26423e8a3990e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150303Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67155}
-
Clemens Backes authored
Sometimes we were triggering a wasm code GC at a time where all native modules just died. Thus, no isolates took part in that GC, and it never finished (because no isolate would ever call {ReportLiveCodeForGC}). This never-ending GC would then block all other GCs for the rest of the life of this wasm engine. This CL fixes this by just finishing the GC immediately if no isolates are outstanding. R=ahaas@chromium.org Change-Id: I4c25dd6ba4132cf9f72de39c30da5d5cba0526ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150588 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I5afad8ef0c5bf2ccad61d71fcc0c89db48851e24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147148 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by:
-
Zhao Jiazhong authored
Port 325e3290 https://crrev.com/c/2147594 Change-Id: If453f75dbf632d84817eca254d0b31e095d5bebb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147590Reviewed-by:
-
jing.bao authored
Bug: v8:9909 Change-Id: I04e50b02f52c24dd39ff3edb26cbaf8843b6910a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147594Reviewed-by:
-
Zhao Jiazhong authored
Port 4558c1df https://crrev.com/c/2141654 Original Commit Message: As a drive-by, the order of rounding_average_u is adjusted according to src/wasm/wasm-opcodes.h. Change-Id: Ia2d39753f618f10e0795f83daa7e5a63f49f554a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147578Reviewed-by:
-
- 14 Apr, 2020 7 commits
-
-
Andreas Haas authored
When memory.grow was executed concurrently on multiple threads a data race could happen such that two memory.grow operations result in the same return value. With this CL the return value of memory.grow is unique, given that memory.grow actually grows the memory. As a concrete example, assume a shared WebAssembly memory initially has a size of 100. Assume two threads call memory.grow concurrently with a parameter `10`. Then with the existing code, memory would grow correctly to a size of 120, but the data race may cause both memory.grow operations to return 100. With the change in this CL one memory.grow operation would return 100, the other would return 110. R=gdeepti@chromium.org CC=rreverser@google.com Bug: chromium:1067621 Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113Reviewed-by:
Ben Smith <binji@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: I9145ac93392073f01e2df9fec8eeae0b6e75dd00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2145238 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: I38e3a8d8915148107b7ff810e1e28c97351da65a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2145237Reviewed-by:
-
Thibaud Michaud authored
R=ahaas@chromium.org Bug: v8:10328 Change-Id: I19ecad9161ea61b4c8a22f80f8ac10ebf23dee53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148783 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Andreas Haas authored
The CL also mooves the {ClearRegister} function to the platform-independent LiftoffAssembler code. R=clemensb@chromium.org Bug: v8:10108 Change-Id: Ibf9f1829a525c859ad004636f678b82aa72d39ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129637 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:Jacob Bramley <jacob.bramley@arm.com> Reviewed-by:
-
Clemens Backes authored
This reverts commit f2ea42d6. Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10634 Original change's description: > [wasm-debug-eval] Implement additional evaluator API methods > > This CL implements the __getLocal and __sbrk APIs of the evaluator > interface. Also includes a drive-by fix of the imports' module: put > them on the "env" module. > > Change-Id: Ie16d1b1cf924b88734eda184d1ce98d52f32f828 > Bug: chromium:1020120 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132786 > Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67122} TBR=jkummerow@chromium.org,pfaffe@chromium.org Change-Id: I23b078d37971e083c08c9b83994bbf38ac13f103 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1020120 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148787Reviewed-by:
-
Clemens Backes authored
We were still occasionally failing tests because sometimes non-debug Liftoff code was published *after* debug Liftoff code. This would overwrite the debug code and we would not stop on function entry then. This fixes this by only preferring Liftoff code in publishing if it has been compiled for debugging. As a side effect, this will also prefer TurboFan code which has been compiled for debugging (i.e. Liftoff bailed out), but this would only happen for experimental features and in this case we will just overwrite TurboFan code with TurboFan code, which is fine. R=thibaudm@chromium.org Bug: v8:10410 Change-Id: I6516e9f474f6118f0f0c077e6789f604ca128e74 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144122Reviewed-by:
-
