- 10 Jul, 2020 1 commit
-
-
Ng Zhi An authored
- was missing an import sys - check for long - check for xrange This file is now flake8 warning free, and should work on both Py2 and Py3. $ flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics Bug: v8:8594 Change-Id: Iae857f4686bcad509fa700954b7f30f86150739f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288177Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#68809}
-
- 19 Jun, 2020 1 commit
-
-
Clemens Backes authored
Replace by "consistency check", or "validity check", or more specific wording as appropriate. R=ecmziegler@chromium.org Bug: v8:10619 Change-Id: Ifd7852d8f703d5b784d53671b82d65db15722ede Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253855Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68440}
-
- 06 May, 2020 1 commit
-
-
Jakob Gruber authored
The serializer currently cannot handle a heap state containing arbitrary compiled Code objects. As a quick fix for the --stress-snapshot d8 flag, we clear compiled data from the isolate prior to the serialize-deserialize-verify pass. With this change, mjsunit tests pass on x64. The %SerializeDeserializeNow() runtime function would require more work, since it is not possible to mutate the heap to this extent while still preserving a runnable host context and isolate. We will need another solution there. Drive-by: Skip the stress_snapshot variant except for the mjsunit suite. Tbr: machenbach@chromium.org Bug: v8:10493,v8:10416 Change-Id: Ie110da8b51613fcd69c7f391d3cf8589d6b04dd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182429Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67585}
-
- 28 Apr, 2020 1 commit
-
-
Paolo Severini authored
This changelist makes the GDB-stub actually execute GDB-remote commands, by accessing the Wasm engine state. More precisely: - class GdbServer registers DebugDelegates that receive debug notifications when a new Wasm module is loaded, when execution suspends at a breakpoint or for an unhandled exception. - Since the GDB-remote commands arrive on a separate thread, all queries from the debugger are transformed into Task objects, that are posted into a TaskRunner that runs in the Isolate thread. - class WasmModuleDebug contains the logic to retrieve the value of globals, locals, memory ranges from the Wasm engine and to add/remove breakpoints. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Test with: python tools\run-tests.py --outdir=out\debug_x64 debugging -j 1 Bug: chromium:1010467 Change-Id: I9703894620a027d3c920926db92e2ff809d84ab8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941139Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#67412}
-
- 20 Feb, 2020 1 commit
-
-
Paolo Severini authored
This is the first piece of the wasm debugging prototype (besides the changes to add/remove breakpoints in WasmModuleObject made with https://chromium.googlesource.com/v8/v8.git/+/e699f39caed9a23f8e20bd3a0386a3236e272737). This changelist adds the infrastructure for a GDB-remote stub that will be used to manage debugging sessions via the gdb-remote protocol. It enables the creation and termination of debugging sessions over TCP connections that are managed in a separate thread. The logic to actually send, receive and decode GDB-remote packets will be part of a future changelist. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Enables Wasm debugging with LLDB (default: false) --wasm-gdb-remote-port TCP port to be used for debugging (default: 8765) --wasm-pause-waiting-for-debugger Pauses the execution of Wasm code waiting for a debugger (default: false) --trace-wasm-gdb-remote Enables tracing of Gdb-remote packets (default: false) Note that most of this code is "borrowed" from the code of the Chromium NaCL GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub). Implementation details: - class GdbServer acts as a singleton manager for the gdb-remote stub. It is instantiated as soon as the first Wasm module is loaded in the Wasm engine. - class GdbServerThread spawns the worker thread for the TCP connection. - class Transport manages the socket connection, in a portable way. - class Session represents a remote debugging session. - class Target represents a debugging target and it’s the place where the debugging packets will be processed and will implement the logic to debug a Wasm engine. Bug: chromium:1010467 Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66379}
-