1. 21 Apr, 2021 1 commit
  2. 12 Apr, 2021 1 commit
  3. 02 Apr, 2021 1 commit
  4. 10 Mar, 2021 1 commit
  5. 23 Feb, 2021 2 commits
  6. 09 Feb, 2021 1 commit
  7. 18 Jan, 2021 1 commit
  8. 24 Nov, 2020 1 commit
  9. 07 Oct, 2020 1 commit
  10. 14 Sep, 2020 1 commit
  11. 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
  12. 02 Jul, 2020 1 commit
  13. 03 Jun, 2020 1 commit
  14. 11 May, 2020 1 commit
  15. 17 Apr, 2020 1 commit
  16. 09 Mar, 2020 1 commit
  17. 04 Mar, 2020 1 commit
  18. 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
  19. 18 Feb, 2020 1 commit
  20. 13 Feb, 2020 1 commit
  21. 18 Dec, 2019 1 commit
  22. 04 Nov, 2019 1 commit
  23. 31 Oct, 2019 1 commit
  24. 29 Oct, 2019 1 commit
  25. 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
  26. 15 Oct, 2019 2 commits
  27. 07 Oct, 2019 1 commit
  28. 20 Sep, 2019 1 commit
    • Seth Brenith's avatar
      [tools] Use instance types of known Maps in v8_debug_helper · 1d3c4975
      Seth Brenith authored
      If we can read an object's Map pointer but not any data from the Map
      itself, we may still be able to accurately describe the object's type if
      the Map pointer matches one of the known Maps from the snapshot.
      GetObjectProperties uses that data in one of two ways:
      - If it is sure that the Map pointer matches a known Map, then it uses
        the type from that Map and continues as if it read the type normally.
      - If the Map pointer is at the right offset within a heap page to match
        a known Map, but the caller didn't provide the addresses of the first
        pages in Map space or read-only space, then the type of that Map is
        just a guess and gets returned in a separate array. This gives the
        caller the opportunity to present guessed types to the user, and
        perhaps call again using the guessed type as the type hint.
      
      Bug: v8:9376
      Change-Id: I187f67b77e76699863a14534a9d635b79f654124
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787986
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63908}
      1d3c4975
  29. 12 Aug, 2019 1 commit
  30. 31 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Reland "Add postmortem debugging helper library" · 0921e8f2
      Seth Brenith authored
      This is a reland of 517ab73f
      
      Updates since original: now compressed pointers passed to the function
      GetObjectProperties are required to be sign-extended. Previously, the
      function allowed zero-extended values, but that led to ambiguity on
      pointers like 0x88044919: is it compressed or is the heap range actually
      centered on 0x100000000?
      
      Original change's description:
      > Add postmortem debugging helper library
      >
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      >
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      >
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      >
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      >
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      >
      > Bug: v8:9376
      >
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      Bug: v8:9376
      Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63008}
      0921e8f2
  31. 24 Jul, 2019 1 commit
    • Zhi An Ng's avatar
      Revert "Add postmortem debugging helper library" · 6747e3a1
      Zhi An Ng authored
      This reverts commit 517ab73f.
      
      Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
      
      Original change's description:
      > Add postmortem debugging helper library
      > 
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      > 
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      > 
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      > 
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      > 
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      > 
      > Bug: v8:9376
      > 
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9376
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62899}
      6747e3a1
  32. 23 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Add postmortem debugging helper library · 517ab73f
      Seth Brenith authored
      This change begins to implement the functionality described in
      https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      for investigating V8 state in crash dumps.
      
      This change adds a new library, v8_debug_helper, for providing platform-
      agnostic assistance with postmortem debugging. This library can be used
      by extensions built for debuggers such as WinDbg or lldb. Its public API
      is described by debug-helper.h; currently the only method it exposes is
      GetObjectProperties, but we'd like to add more functionality over time.
      The API surface is restricted to plain C-style structs and pointers, so
      that it's easy to link from a debugger extension built with a different
      toolchain.
      
      This change also adds a new cctest file to exercise some basic
      interaction with the new library.
      
      The API function GetObjectProperties takes an object pointer (which
      could be compressed, or weak, or a SMI), and returns a string
      description of the object and a list of properties the object contains.
      For now, the list of properties is entirely based on Torque object
      definitions, but we expect to add custom properties in future updates so
      that it can be easier to make sense of complex data structures such as
      dictionaries.
      
      GetObjectProperties does several things that are intended to generate
      somewhat useful results even in cases where memory may be corrupt or
      unavailable:
      - The caller may optionally provide a type string which will be used if
        the memory for the object's Map is inaccessible.
      - All object pointers are compared against the list of known objects
        generated by mkgrokdump. The caller may optionally provide the
        pointers for the first pages of various heap spaces, to avoid spurious
        matches. If those pointers are not provided, then any matches are
        prefixed with "maybe" in the resulting description string, such as
        "maybe UndefinedValue (0x4288000341 <Oddball>)".
      
      Bug: v8:9376
      
      Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62882}
      517ab73f
  33. 24 Jun, 2019 1 commit
  34. 18 Jun, 2019 1 commit
  35. 28 May, 2019 1 commit
  36. 27 May, 2019 1 commit
    • Peter Marshall's avatar
      [tracing] Add a way to test perfetto traces. · d365f62e
      Peter Marshall authored
      Add a new abstract class TraceEventListener which is just an interface
      for consuming trace events. This separates the V8-specific stuff that
      an actual perfetto consumer needs to do e.g. handling the has_more flag
      and signalling back to the controller with a semaphore.
      
      This is a change from the previous plan of making the PerfettoConsumer
      class sub-classable to implement custom consumption of trace events.
      This will be difficult when the consumer is created outside of the
      PerfettoTracingController as we can't hook up the
      consumer_finished_semaphore_ that belongs to the controller.
      
      Now the PerfettoTracingController is responsible for the Consumer life-
      cycle and hides it entirely from callers. We add the
      AddTraceEventListener() method to allow callers to register a listener
      either for testing or a JSON listener for real tracing.
      
      This lets us write tests that can store all the trace events in memory
      without first converting them to JSON, letting us write test more
      easily. There's an example test add to test-tracing - more tests using
      this style will follow.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
      Bug: v8:8339
      Change-Id: I2d2b0f408b1c7bed954144163e1968f40d772c1b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628789
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Auto-Submit: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61854}
      d365f62e
  37. 15 May, 2019 2 commits