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: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81856}