1. 01 Apr, 2022 1 commit
  2. 18 Feb, 2022 1 commit
  3. 16 Feb, 2022 1 commit
  4. 02 Feb, 2022 1 commit
  5. 01 Feb, 2022 1 commit
  6. 26 Jan, 2022 2 commits
  7. 20 Jan, 2022 1 commit
  8. 20 Dec, 2021 1 commit
    • Nico Weber's avatar
      Make creating x64 snapshots on arm64 hosts mostly work · 5f644d7e
      Nico Weber authored
      The motivation is being able to build Chrome/Mac/Intel on an
      Apple Silicon mac.
      
      Depends on https://chromium-review.googlesource.com/c/chromium/src/+/3348020
      
      - Correctly set v8_snapshot_toolchain when targeting x64 on an arm64
        host (always use the clang_ toolchain for now since that's all
        that's needed at the moment)
      
      - Check V8_HOST_ARCH in immediate-crash.h. In V8 terminology, "host"
        is the machine the snapshot generation runs on, while "target" is the
        machine that V8 runs on when it JITs. IMMEDIATE_CRASH runs on the
        host. Up to now, target arch x64 implied host arch x64 so the old code
        happened to work too, but this is the correct macro (and it makes this
        cross scenario work).
      
      - In assembler-x64.cc, only compile the code that probes the current CPU
        when running on an intel host. (There's an early return for snapshot
        generation anyways.)
      
      Bug: chromium:1280968
      Change-Id: I4821a5994de8ed5f9e4f62184dc6ab6f5223bc3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3348040Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Nico Weber <thakis@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78417}
      5f644d7e
  9. 16 Aug, 2021 1 commit
  10. 13 Aug, 2021 1 commit
  11. 12 Aug, 2021 1 commit
  12. 07 Jul, 2021 1 commit
  13. 21 Apr, 2021 1 commit
  14. 12 Apr, 2021 1 commit
  15. 02 Apr, 2021 1 commit
  16. 10 Mar, 2021 1 commit
  17. 23 Feb, 2021 2 commits
  18. 09 Feb, 2021 1 commit
  19. 18 Jan, 2021 1 commit
  20. 24 Nov, 2020 1 commit
  21. 07 Oct, 2020 1 commit
  22. 14 Sep, 2020 1 commit
  23. 31 Aug, 2020 1 commit
    • Jake Hughes's avatar
      [heap] Add object start bitmap for conservative stack scanning · 5f6aa2e5
      Jake Hughes authored
      With conservative stack scanning enabled, a snapshot of the call stack
      upon entry to GC will be used to determine part of the root-set. When
      the collector walks the stack, it looks at each value and determines
      whether it could be a potential on-heap object pointer. However, unlike
      with Handles, these on-stack pointers aren't guaranteed to point to the
      start of the object: the compiler may decide hide these pointers, and
      create interior pointers in C++ frames which the GC doesn't know about.
      
      The solution to this is to include an object start bitmap in the header
      of each page. Each bit in the bitmap represents a word in the page
      payload which is set when an object is allocated. This means that when
      the collector finds an arbitrary potential pointer into the page, it can
      walk backwards through the bitmap until it finds the relevant object's
      base pointer. To prevent the bitmap becoming stale after compaction, it
      is rebuilt during object sweeping.
      
      This is experimental, and currently only works with inline allocation
      disabled, and single generational collection.
      
      Bug: v8:10614
      Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69615}
      5f6aa2e5
  24. 02 Jul, 2020 1 commit
  25. 03 Jun, 2020 1 commit
  26. 11 May, 2020 1 commit
  27. 17 Apr, 2020 1 commit
  28. 09 Mar, 2020 1 commit
  29. 04 Mar, 2020 1 commit
  30. 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
  31. 18 Feb, 2020 1 commit
  32. 13 Feb, 2020 1 commit
  33. 18 Dec, 2019 1 commit
  34. 04 Nov, 2019 1 commit
  35. 31 Oct, 2019 1 commit
  36. 29 Oct, 2019 1 commit
  37. 16 Oct, 2019 1 commit
    • Simon Zünd's avatar
      Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" · 69efc4c3
      Simon Zünd authored
      This is a reland of 1c56974f
      
      This is a plain reland of the original CL. The original CL was speculatively
      reverted, but ended up not being the cause for bot failures.
      
      Original change's description:
      > Unconditionally enable snapshot builds and remove 'v8_use_snapshot'
      >
      > This CL removes 'v8_use_snapshot' and the usages of the implied
      > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the
      > "asan" variant instead of the now obsolete "no_snap" variant.
      >
      > Related chromium CL: https://crrev.com/c/1796325.
      >
      > Bug: v8:8531
      > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Reviewed-by: Nico Weber <thakis@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64290}
      
      TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org
      
      Bug: v8:8531
      Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64305}
      69efc4c3
  38. 15 Oct, 2019 1 commit