We want to be consistent with wasdk/wasmparser.
The names used in V8 should follow the WAT convention and always start
with a dollar, both for names from the "names" section as well as
generated names.
Bug: v8:10242
Change-Id: If4dbd4c38208c9dd9377dd2f79120635a531d881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070637
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66434}
This extends the existing test to also print scope information on every
break. Note that the currently printed information is not correct, since
register values are not reconstructed yet. We just always print {-11}
for register values.
Thus the expected output will change with follow-up CL.
R=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I7be13ecb02957454c875a4280cec154a08c2deb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062403
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66433}
After compiling a function with a different set of breakpoints, update
return addresses on the stack so that execution resumes in the new
code.
This allows new breakpoints to take effect immediately, which is the
expected behavior and a prerequisite for stepping.
R=clemensb@chromium.org
Bug: v8:10147
Change-Id: I67eb3b4ce23a1f3b0519935447f8b847ec888ead
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064218
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66351}
By replacing usage of the IsNotArrayIndex bit with IsNotIntegerIndex,
we get back one bit that we can use to increase the number of hash bits
stored. The price is that strings that represent array/integer indices
beyond the cacheable range will have to be scanned more often, but these
strings should be rare, and we expect that the additional hash bit is
more worthwhile to have.
Bug: v8:9904
Change-Id: I33f74b0a73f4754aee85805d4b7c409177668439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051947
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66299}
If new Liftoff code is generated but we already have either Liftoff or
TurboFan code, we still want to install and use the new Liftoff code if
we are in debugging.
This logic can probably be simplified again when the "tier down to
liftoff on Debugger.enable" logic is fully implemented. I left a TODO to
revisit the logic later.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ie3a6bdf1cde4f1af884edc8cf1f1b5a507283a5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036089
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66129}
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: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65921}
