Commit Graph

3 Commits

Author SHA1 Message Date
Jakob Gruber
3c422d1c5e [snapshot] Clear reconstructable data prior to d8 stress_snapshot run
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/+/2182429
Reviewed-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}
2020-05-06 07:11:22 +00:00
Paolo Severini
74e9318689 Wasm debugging with LLDB: access Wasm engine state
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/+/1941139
Reviewed-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}
2020-04-28 01:02:32 +00:00
Paolo Severini
03fc414908 Add initial support for Wasm debugging with LLDB: implements a GDB-remote stub
This is the first piece of the wasm debugging prototype (besides the changes to
add/remove breakpoints in WasmModuleObject made with
e699f39cae).

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/+/1923407
Reviewed-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}
2020-02-20 22:27:58 +00:00