1. 18 Jul, 2022 1 commit
    • Liviu Rau's avatar
      [test] Refactor testrunner (4) · b3477fdd
      Liviu Rau authored
       - Removed duplication and unnecessary indirection from all suites testcfgs.
       - Introduced a more comprehensive context to cover both command context and other platform specific concerns.
       - Propagated above context to TestLoader to allow for test counting command execution on all platforms.
       - Wrapped original pool with another class to give it a new interface and allow injecting different implementations in the future.
       - Consolidated progress indicators under a single processor in the pipeline.
       - Consolidated result retention requirements calculation outside of pipeline chain.
       - Refactored LoaderProc and got it under tests.
       - Added some more tests for the standard runner.
       - Extracted BuildConfig class.
      
      
      Bug: v8:12785
      Change-Id: I87be040e91f792a983662bb5a10d55b36a14ea7f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3701595Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Liviu Rau <liviurau@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81770}
      b3477fdd
  2. 01 Jun, 2021 1 commit
  3. 22 Mar, 2021 1 commit
  4. 08 Dec, 2020 1 commit
  5. 20 Oct, 2020 1 commit
  6. 10 Jul, 2020 1 commit
  7. 19 Jun, 2020 1 commit
  8. 06 May, 2020 1 commit
    • Jakob Gruber's avatar
      [snapshot] Clear reconstructable data prior to d8 stress_snapshot run · 3c422d1c
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67585}
      3c422d1c
  9. 28 Apr, 2020 1 commit
    • Paolo Severini's avatar
      Wasm debugging with LLDB: access Wasm engine state · 74e93186
      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: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#67412}
      74e93186
  10. 20 Feb, 2020 1 commit
    • Paolo Severini's avatar
      Add initial support for Wasm debugging with LLDB: implements a GDB-remote stub · 03fc4149
      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: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66379}
      03fc4149