1. 05 Aug, 2022 1 commit
    • Michael Achenbach's avatar
      [infra] Change all Python shebangs to Python3 · 6ea78398
      Michael Achenbach authored
      The infrastructure runs everything already in Python3, so this is
      mostly a clean-up.
      
      For MB, a python2 holdover was removed and new lint errors were
      fixed.
      
      The renames were automated with:
      git grep -e "/usr/bin/python$" |
        cut -d':' -f1 |
        xargs
        sed -i 's/#!\/usr\/bin\/python$/#!\/usr\/bin\/python3/1'
      
      and
      git grep -e "/usr/bin/env python$" |
        cut -d':' -f1 |
        xargs
        sed -i 's/#!\/usr\/bin\/env python$/#!\/usr\/bin\/env python3/1'
      
      Bug: v8:13148
      Change-Id: If4f3c7635e72fa134798d55314ac1aa92ddd01bf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811499Reviewed-by: 's avatarLiviu Rau <liviurau@google.com>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82231}
      6ea78398
  2. 20 Jul, 2022 1 commit
    • 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
  3. 18 May, 2022 1 commit
    • Seth Brenith's avatar
      [v8windbg] Skip undefined types in Torque structs · 3a558456
      Seth Brenith authored
      The test cctest/test-v8windbg recently started failing because the
      v8windbg debugger extension is unable to read the "flags" field on a
      SharedFunctionInfo instance. This occurs because one of the bitfields
      within "flags" has type OSRCodeCacheStateOfSFI, which is only declared
      using an "opaque enum declaration":
      
        enum OSRCodeCacheStateOfSFI : uint8_t;
      
      When WinDbg fails in its attempt to look up that type, v8windbg responds
      by failing to construct anything at all for "flags". However, the other
      17 bitfields in "flags" can be represented successfully, so a more
      useful behavior is to just skip the one failed entry.
      
      Change-Id: I40630548d21499e49f0214da28260318a38d9360
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3653096Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#80615}
      3a558456
  4. 13 Dec, 2021 1 commit
  5. 18 Nov, 2021 1 commit
  6. 06 Oct, 2021 1 commit
  7. 14 Jul, 2021 1 commit
  8. 28 Apr, 2021 2 commits
  9. 10 Apr, 2021 1 commit
  10. 07 Apr, 2021 1 commit
  11. 25 Mar, 2021 1 commit
  12. 26 Nov, 2020 1 commit
  13. 11 Nov, 2020 1 commit
    • Seth Brenith's avatar
      Fix v8windbg failure on non-ptr-compr builds · 2388f2c1
      Seth Brenith authored
      On builds without pointer compression enabled, v8windbg currently fails
      to display information about objects in the Locals pane. This is because
      some important code to get a type name was hidden behind a
      COMPRESS_POINTERS_BOOL check. The existing cctest
      test-v8windbg/V8windbg is sufficient to catch this error, but apparently
      nobody ever runs that test in the failing configuration (Windows,
      symbol_level = 2, v8_enable_pointer_compression = false).
      
      Change-Id: Ia4e2714b11e6854b3f4f6b72da4ae8c352e8cddc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2530413Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71124}
      2388f2c1
  14. 21 Sep, 2020 2 commits
  15. 23 Jun, 2020 1 commit
  16. 22 Jun, 2020 1 commit
  17. 09 Mar, 2020 1 commit
    • Seth Brenith's avatar
      [tools] Fix v8windbg behavior on Map's bit_field2 · 8b1a5681
      Seth Brenith authored
      Bill kindly pointed out to me that v8windbg was not handling bit_field2
      correctly. The issue was that the constexpr type for ElementsKind was,
      somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully-
      qualified type name like "v8::internal::ElementsKind". This change
      addresses the problem in two ways:
      1. Update v8windbg's type resolution logic to resolve type names as if
         they were used in the v8::internal namespace. This makes it more
         consistent with how those type names are used in other generated
         Torque code, reducing surprises and the number of times we have to
         write `v8::internal::` in .tq files.
      2. Add compile-time verification that any constexpr type name used as a
         string in class-debug-readers-tq.cc can also resolve as a type name.
      
      Bug: v8:9376
      Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66633}
      8b1a5681
  18. 18 Feb, 2020 1 commit