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/+/3811499
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82231}
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/+/3759228
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81856}
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/+/3653096
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80615}
In order to determine which module contains V8, v8windbg has been
looking for the known symbol v8::Script::Run. However, that symbol might
not be found if the function was inlined. To fix, we should instead
choose a symbol that is declared with V8_NOINLINE.
Change-Id: Ib73dfb27f35ab81ab69f92ffab944f6f1096b895
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3290107
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77974}
Use relative paths to access v8 root build rules since // means
something different in a chrome build.
Bug: v8:7330
Change-Id: I4eac73b394daaf0250b0fa2ad415af560b03c114
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2856840
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74258}
This command is broken, no testing and no clear demand for it.
Change-Id: Ic86ab346ab29a5d6804f74a3d4458bb3332a7718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814131
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73888}
Scopes in V8 are used to guarantee one or more properties during its
lifetimes. If a scope is not named e.g MyClassScope(args) instead of
MyClassScope scope(args) it will get created and automatically destroyed
and therefore, being useless as a scope. This CL would produce a
compiling warning when that happens to ward off this developer error.
Follow-up to ccrev.com/2552415 in which it was introduced and
implemented for Guard classes.
Change-Id: Ifa0fb89cc3d9bdcdee0fd8150a2618af5ef45cbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555001
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71425}
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/+/2530413
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71124}
For js frame, we want to display currently executing function.
Change-Id: If33b04279dafdf6e4834bfb6c7240e8e7e799fc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411483
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70018}
Get value from type payload, check and show bitset name.
Change-Id: I6d0e0f30fca0b2aaddfd5f18abf948886552f2dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2258815
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#68495}
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/+/2063769
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66633}
Please take a look at tools/v8windbg/README.md for an overview of what
v8windbg can do and how it's structured. This platform-specific
debugging plugin makes use of the data provided by the V8 postmortem
debugging API in tools/debug_helper.
Note: This code began as https://github.com/billti/v8dbg and then moved
into the Edge repository, where I added features gradually and got code
reviews for individual changes. Now, taken in its entirety, it's an
obnoxiously large CL. I'm open to breaking it up into a few chunks if
that would be preferable.
Bug: v8:9376
Change-Id: I3e503de00bb1aea870ae83e9bd99e4e2eab9ef98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031700
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66319}
