1. 08 Feb, 2021 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Delta-encode the debug side table · 392a0251
      Clemens Backes authored
      For functions with a very large stack, the debug side table repeats a
      lot of information: Most values will be spilled to the stack, still
      every single entry in the debug side table repeats information about
      them (type, stack offset). This leads to the size of the debug side
      table to be quadratic in the size of the function.
      
      In the linked bug, the generation of the debug side table took ~400ms,
      whereas Liftoff compilation alone just took 16ms.
      
      This CL optimized the debug side table by delta-encoding the entries,
      i.e. only storing stack slots that changed. This reduces the size of the
      table significantly, at the cost of making lookup slower, since that now
      has to search the table backwards for the last entry that had
      information about a specific slot. For now, this seems like a good
      compromise. If it turns out to be a problem, we could speed up the
      lookup by either forcing a full dump of the stack state after N entries,
      or by dynamically inserting new entries during lookup, whenever we find
      that we had to search backwards more than N entries. That would speed up
      subsequent lookups then.
      
      On the reproducer in the linked bug, this change reduces the time to
      generate the debug side table from ~400ms to ~120ms.
      Before this CL, the debug side table has 13,314 entries with a total of
      38,599,606 stack value entries. After this CL, it shrinks to 20,037
      stack value entries in the 13,314 entries (average of ~1.5 instead of
      ~2,899).
      
      R=thibaudm@chromium.org
      
      Bug: chromium:1172299
      Change-Id: Ie726bb82d4c6648cc9ebd130115ee7ab3d1d551b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676636Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72558}
      392a0251
  2. 13 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [wasm][debug] Simplify debug name handling. · 1bd5755b
      Benedikt Meurer authored
      This moves the logic for the debug name heuristic, which derives names
      for imported and exported entities from the relevant tables, into
      wasm-debug.{cc,h} and stores these maps on the DebugInfoImpl rather than
      on the WasmModule.
      
      Drive-by-fix: Also use the import table based heuristic for function
      names, just like we use it for everything else.
      
      Bug: chromium:1164305
      Change-Id: I8a21e0880c680079f63e6607b5b62c788049b9e1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625870
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72061}
      1bd5755b
  3. 11 Jan, 2021 1 commit
  4. 08 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Implement Debug Proxy API via Interceptors. · c27c167c
      Benedikt Meurer authored
      Previously the Debug Proxy API that's exposed on Wasm frames by
      Runtime.evaluateOnCallFrame() was implemented via actual JSProxy
      instances. That means that all entities such as "memories", "tables",
      "stack", "globals", etc. were JSProxy instances with "get" and "has"
      traps. But that has a couple of down-sides:
      
      1. In DevTools front-end, the proxies are shown as JSProxy, which is not
         very useful to developers, since they cannot interact with them nor
         can they inspect their contents. And the object preview also only
         shows "Proxy {}" for them.
      2. The performance doesn't scale well, which becomes a painful
         bottleneck with larger Wasm modules that contain hundreds of
         thousands of functions or globals.
      3. We cannot use the JSProxy instances in the Scope view (for the
         reasons outlined in 1.) and hence we have different logic to provide
         Scope values than values in the rest of DevTools, which led to subtle
         but annoying bugs and inconsistencies.
      
      This also changes the "locals" implementation by querying the values
      ahead of time, similar to the object exposed to the Scope view, instead
      of on-demand, since the "locals" object might survive the current
      debugger pause and peeking into the stack afterwards would read invalid
      memory (and might even be a security issue). For being able to change
      locals we need to look into a similar solution as what we have for
      JavaScript locals already. The expression stack already works this way.
      
      For performance reasons (especially scaling to huge, realistic Wasm
      modules), we cache the per-instance proxies ("functions", "memories",
      "tables" and "globals") on the WasmInstanceObject and reuse them (which
      is safe since they have a `null` prototype and are non-extensible), and
      we also cache the proxy maps (with the interceptors) on the
      JSGlobalObject per native context.
      
      Doc: http://bit.ly/devtools-wasm-entities
      Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241
      Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71981}
      c27c167c
  5. 05 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug][wasm] Move DebugEvaluate implementation to wasm-debug.cc. · 5fc4649d
      Benedikt Meurer authored
      Previously the proxies that make up the DebugEvaluate implementation for
      Wasm frames lived in wasm-js.cc, but that was quite confusing since
      
      (a) the rest of the debug support for Wasm lives in wasm-debug.cc (and
          we intend to eventually unify the DebugEvaluate and Scope objects),
          and
      (b) the wasm-js.cc file is explicitly about the WebAssembly JS API
          that's part of the WebAssembly specification, and the DebugEvaluate
          proxies aren't part of that.
      
      Bug: chromium:1162229, chromium:1071432, chromium:1127914
      Change-Id: I63016dcace6d8e2af4a03c8eed4f02d464c1dee1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609418
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71911}
      5fc4649d
  6. 26 Nov, 2020 1 commit
  7. 25 Nov, 2020 1 commit
  8. 05 Oct, 2020 1 commit
  9. 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
  10. 26 May, 2020 1 commit
  11. 18 May, 2020 1 commit
  12. 11 May, 2020 1 commit
  13. 24 Apr, 2020 1 commit
  14. 16 Apr, 2020 1 commit
  15. 15 Apr, 2020 1 commit
  16. 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
  17. 26 Mar, 2020 1 commit
  18. 23 Mar, 2020 1 commit
  19. 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
  20. 13 Mar, 2020 2 commits
  21. 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
  22. 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
  23. 19 Feb, 2020 1 commit
  24. 04 Feb, 2020 1 commit
  25. 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
  26. 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
  27. 15 Jan, 2020 1 commit
  28. 09 Jan, 2020 1 commit
  29. 27 Dec, 2019 1 commit
  30. 17 Dec, 2019 1 commit
  31. 06 Dec, 2019 1 commit
  32. 26 Nov, 2019 1 commit
  33. 24 Oct, 2019 1 commit
  34. 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
  35. 19 Oct, 2016 1 commit
  36. 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
  37. 29 Jun, 2016 1 commit
  38. 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
  39. 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