1. 05 Oct, 2020 1 commit
  2. 28 May, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Support multi-threaded stepping · 97434791
      Clemens Backes authored
      Instead of keeping a single {stepping_frame_} per native module, we now
      keep one frame id per isolate. Hence, each isolate can step through a
      different frame, independent of other isolates.
      The on-stack-replacement of the stepping frame already works on a
      per-isolate basis, since we only replace the return address of a single
      frame, part of the isolate that requested stepping.
      
      The new test (which also executes in a variant with two concurrent
      isolates) revealed some more data races to fix.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: I0bb013737162bd09b9f4be9c08990bca7bf736ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214838Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68045}
      97434791
  3. 26 May, 2020 1 commit
  4. 18 May, 2020 1 commit
  5. 11 May, 2020 1 commit
  6. 24 Apr, 2020 1 commit
  7. 16 Apr, 2020 1 commit
  8. 15 Apr, 2020 1 commit
  9. 30 Mar, 2020 1 commit
    • Clemens Backes's avatar
      [liftoff][debug] Fix step in from JS · 788bffd5
      Clemens Backes authored
      When stepping in from JS, the stepping frame ID will not be set.
      Instead of ensuring to set it properly, we can just skip the check for
      the frame ID. It was needed before, when we didn't properly reset
      stepping information. Now, it's redundant anyway.
      
      Also, ensure that we don't redirect to the interpreter if the
      --debug-in-liftoff flag is set.
      
      Drive-by: Fix and clang-format some parts of the test (no semantic
      change).
      
      R=thibaudm@chromium.org, szuend@chromium.org
      
      Bug: v8:10351
      Change-Id: I58a3cd68937006c2d6b755a4465e793abcf8a20c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124317Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66904}
      788bffd5
  10. 26 Mar, 2020 1 commit
  11. 23 Mar, 2020 1 commit
  12. 16 Mar, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Load register values from DebugBreak frame · ae03752f
      Clemens Backes authored
      This implements inspection of live registers on breakpoints in Liftoff.
      To that end, the frame pointer of the WasmDebugBreak frame is remembered
      when iterating the stack. Based on a platform-specific implementation of
      {WasmDebugBreakFrameConstants}, the offset of the respective register
      within that frame is computed, and the value is read from the frame.
      
      As a drive-by, the wasm debug side table is storing register codes as
      liftoff codes, which can also store register pairs (needed for i64 on
      32-bit platforms, and for SIMD, which is not supported yet).
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66719}
      ae03752f
  13. 13 Mar, 2020 2 commits
  14. 24 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Extend debug side table for registers · 75931f18
      Clemens Backes authored
      This extends the debug side table to also store register locations in
      addition to constants and stack values.
      Previously, every value that was not constant was assumed to be spilled
      to the stack. This made sense, because without breakpoints we would only
      emit debug side table entries at call sites, where all registers are
      spilled.
      With breakpoints, this changes. At break locations, values might be live
      in registers.
      
      The logic to decide whether a value will live in the register or on the
      stack is extended, because we sometimes generate the debug side table
      entry at a point where the registers are not spilled yet. The debug side
      table entry creation needs to account for that, and assume that these
      registers will still be spilled.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10147, v8:10222
      Change-Id: I3b020dfaa29fc007047663706ee286180a996bfd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066960
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66407}
      75931f18
  15. 20 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Refactor debug side table · 93d35279
      Clemens Backes authored
      This refactors the debug side table such that we can easily add
      register information later.
      In particular
      - vectors for types and stack offsets are combined into one;
      - constants are stored in the same vector;
      - locals and operand stack values are stored in the same vector.
      
      A follow-up CL will extend the DebugSideTable to also encode locals
      or operand stack values held in registers.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10147, v8:10222
      Change-Id: I97adb56b31afdb22896530c7ba2e8a24b5d31da9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062405
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66374}
      93d35279
  16. 19 Feb, 2020 1 commit
  17. 04 Feb, 2020 1 commit
  18. 22 Jan, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] First plumbing for debugging in Liftoff · 7b79a02d
      Clemens Backes authored
      This CL adds a --debug-in-liftoff flag, which takes another path in
      {WasmScript::SetBreakPointForFunction}, and sets the breakpoint via
      {wasm::DebugInfo} (Liftoff-related) instead of {WasmDebugInfo} (C++
      interpreter related).
      Actual breakpoint support is not there yet, so the new test which sets
      this flag does not currently break anywhere. This will change with a
      future CL.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10147
      Change-Id: I95a905e666b8f502366d2c7273c8f25a267ee184
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2012920
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65921}
      7b79a02d
  19. 16 Jan, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Move decoded local names off-heap · c0ee1e28
      Clemens Backes authored
      We were decoding the names of locals into a C++ data structure, and then
      generated a FixedArray out of that, stored in the on-heap WasmDebugInfo.
      In order to support name lookup for debugging with Liftoff, where no
      WasmDebugInfo will be present, this CL refactors the C++ data structure
      to allow direct lookups and stores it in the C++ DebugInfo structure.
      
      With this CL, the names are still only used from the old
      interpreter-based debugging path. A follow-up CL will then also use it
      from Liftoff.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10019
      Change-Id: I1397021b5d69b9346fc26f5e83653360f428c5e7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002541
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65819}
      c0ee1e28
  20. 15 Jan, 2020 1 commit
  21. 09 Jan, 2020 1 commit
  22. 27 Dec, 2019 1 commit
  23. 17 Dec, 2019 1 commit
  24. 06 Dec, 2019 1 commit
  25. 26 Nov, 2019 1 commit
  26. 24 Oct, 2019 1 commit
  27. 11 Nov, 2016 1 commit
    • titzer's avatar
      [wasm] Move all heap-allocated WASM structures into wasm-objects.h. · fa9c25ce
      titzer authored
      This CL moves all heap-allocated WASM data structures, both ones
      that are bonafide JSObjects and ones that are FixedArrays only, into a
      consistent place with consistent layout. Note that not all accessors are complete, and I haven't fully spread the new static typing goodness
      to all places in the code.
      
      R=ahaas@chromium.org,rossberg@chromium.org
      CC=gdeepti@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/2490663002
      Cr-Commit-Position: refs/heads/master@{#40913}
      fa9c25ce
  28. 19 Oct, 2016 1 commit
  29. 12 Oct, 2016 1 commit
    • clemensh's avatar
      [wasm] Provide better stack traces for asm.js code · 5d9fa102
      clemensh authored
      For the asm.js to WASM pipeline, the current stack traces only show
      low-level WASM information.
      This CL maps this back to asm.js source positions.
      It does so by attaching the asm.js source Script to the compiled WASM
      module, and emitting a delta-encoded table which maps from WASM byte
      offsets to positions within that Script. As asm.js code does not throw
      exceptions, we only store a mapping for call instructions.
      
      The new AsmJsWasmStackFrame implementation inherits from
      WasmStackFrame, but contains the logic to provide the source script and
      the position inside of it.
      What is still missing is the JSFunction object returned by
      CallSite.getFunction(). We currently return null.
      
      R=jgruber@chromium.org, titzer@chromium.org
      BUG=v8:4203
      
      Review-Url: https://codereview.chromium.org/2404253002
      Cr-Commit-Position: refs/heads/master@{#40205}
      5d9fa102
  30. 29 Jun, 2016 1 commit
  31. 20 Jun, 2016 1 commit
    • clemensh's avatar
      [wasm] Handlify WasmDebugInfo where needed · 48a96d17
      clemensh authored
      All function which potentially do heap allocations now take a Handle
      on a WasmDebugInfo. This unfortunately requires to make some function
      static, since otherwise the "this" pointer would not be handlified.
      
      R=ahaas@chromium.org, titzer@chromium.org
      BUG=chromium:613110
      
      Review-Url: https://codereview.chromium.org/2074933005
      Cr-Commit-Position: refs/heads/master@{#37099}
      48a96d17
  32. 17 Jun, 2016 1 commit
    • clemensh's avatar
      [wasm] Split off debug info from wasm object · b8238f89
      clemensh authored
      All debugging-related information is now stored inside a dedicated
      object, which is only allocated if debugging support is needed.
      This is also where later a reference to the interpreter will be stored
      for executing to-be-debugged functions and providing stack inspection.
      
      R=titzer@chromium.org, ahaas@chromium.org
      BUG=chromium:613110
      
      Review-Url: https://codereview.chromium.org/2050953003
      Cr-Commit-Position: refs/heads/master@{#37055}
      b8238f89