1. 22 Jul, 2022 20 commits
  2. 21 Jul, 2022 18 commits
  3. 20 Jul, 2022 2 commits
    • Milad Fa's avatar
      PPC [liftoff]: Implement simd load and store · 6934107e
      Milad Fa authored
      Change-Id: Ia45248a3d8566dbb4f2702a8b1ea6959157dc76b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776949
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#81857}
      6934107e
    • Seth Brenith's avatar
      Fix v8windbg Locals pane behavior · 607ad422
      Seth Brenith authored
      Background:
      
      In order to show custom content in the "Locals" pane in WinDbg, v8windbg
      replaces the getter function for a built-in debug model property named
      "Debugger.Models.StackFrame.LocalVariables". This is the property that
      the debugger fetches when determining what to display in "Locals". The
      new implementation of that getter, V8LocalVariables::GetValue, can
      either call the original getter (so that WinDbg displays the usual
      content for normal C++ frames) or produce a custom result (for builtins
      and JIT-compiled JS frames).
      
      The current problem:
      
      In new builds of WinDbg, users of v8windbg no longer see any content in
      the Locals pane for stack frames that correspond to builtins or
      JIT-compiled code. This is because of a behavior change in WinDbg:
      previously, attempting to get Debugger.Models.StackFrame.LocalVariables
      would eagerly attempt to find the symbols for the frame and return an
      error code if symbols were not found, but now it returns a lazy object
      which does not perform symbol lookup until you iterate its properties.
      V8LocalVariables::GetValue currently starts with an early-exit path
      based on checking whether the original getter succeeded, so the new lazy
      implementation causes us to always take that early exit.
      
      Proposed fix:
      
      Rather than relying on the return value from the original getter, which
      is not guaranteed to work consistently, we can base our decisions on the
      instruction pointer. If it points outside any module, or if it points to
      within a function in the module containing V8 whose name starts with
      "Builtins_", then we can build a custom result for the Locals pane.
      
      Change-Id: I6644071d5d83a25b964d9f4018265532528cc85c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3759228Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#81856}
      607ad422