With this CL, V8 adds an internal field to the WebAssembly Table object
that is sent to DevTools to also show table entries. As WebAssembly
Tables get initialized lazily, V8 only shows the name of the function
instead of the function object itself.
Screenshot before change: https://imgur.com/a/XFvy3lA
Screenshot after change: https://imgur.com/kT84kstR=kimanh@chromium.org
Change-Id: I56a0b07785ff3484f1447419fe39ae5ec3f93247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897097
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74690}
This changes the names reported in stack traces via the Chrome DevTools
protocol to follow the WAT naming convention for functions. This aligns
the behavior here with the rest of DevTools (i.e. the disassembly in the
Sources panel and the Scope sidebar, as well as the Console REPL) to use
one consistent naming scheme.
Fixed: chromium:1159307
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1162229, chromium:1164241, chromium:1071432
Change-Id: Ibe543f39c775944072073fe5f0959412529aa19b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878734
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74456}
These tests unnecessarily rely on the `//# sourceURL` annotation. This
is preparatory work to eventually move the treatment of `sourceURL` to
the DevTools front-end.
Bug: chromium:1183990
Change-Id: I934eb1580f503b7b9f8d97c250b7c798bc67e268
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814568
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73878}
This is the V8 side change for https://crrev.com/c/2744048, which an
explicit "stack" property into the (renamed) "Expression" scope to align
the behavior and appearance of that scope with the other scopes.
Fixed: chromium:1159310
Bug: chromium:1071432, chromium:1159307
Change-Id: Ic070c50b674d8c1cff4a93538f708cc431c3f2cb
Screenshot: https://imgur.com/a/ryFiOGA.png
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748591
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73321}
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now
represented as objects instead of holding the (primitive) values
directly, and SIMD128 values are no longer represented as Uint8Arrays.
The DWARF extension has been prepared for this breaking change.
The new `WasmValue` comes with `type` and `value` properties that hold
its contents. The motivation here is that this is a more extensible
approach. In case of SIMD128, the `value` property holds the canonical
string representation, which has the additional advantage that these
values can be compared with `===` (and `==`).
This partially reverts https://crrev.com/c/2614428, the main difference
here being that WasmValue is now a proper JSObject that can be exposed
on the DebugEvaluate proxy API.
Screenshot: https://imgur.com/rcahNKM.png
Bug: chromium:1170282, chromium:1071432, chromium:1159402
Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72570}
This adds the following internal properties to `WasmInstanceObject`
values in DevTools:
- `[[Module]]` pointing to the `WasmModuleObject`, allowing the
developer to find the module to an instance no matter where in
DevTools front-end the instance is inspected.
- `[[Functions]]`, `[[Globals]]`, `[[Memories]]`, and `[[Tables]]`
are shown (when they aren't empty), allowing developers to inspect
the entities within an instance no matter where in DevTools front-end
it's inspected.
This also updates the _Module_ scope for Wasm frames to show the entity
containers (`functions`, `globals`, `memories` and `tables`) in addition
to the `instance` and `module` to make it easier accessible (fewer
clicks to get there), but also to align it better with the _Add property
path to Watch_ and _Copy property path_ features (since exactly the same
names are exposed via Debug Evaluate on Wasm frames).
```
> Stack
> Locals
v Module
> module
> instance
> functions
> globals
> memories
> tables
```
Drive-by-fix: Move GetWasmModuleObjectInternalProperties() logic into
debug-wasm-support.cc
Screenshot: https://imgur.com/ksEHG2I.png
Doc: http://bit.ly/devtools-wasm-entities
Fixed: chromium:1165294
Bug: chromium:1071432, chromium:1164241, chromium:1165304
Change-Id: Ia88fb2705287c79988ff2b432e4a33ac34e098f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622912
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72042}
This change unifies the locals, stack, and globals objects exposed for
WebAssembly frames via the Scope view and via DebugEvaluate to use the
same underlying objects (implemented via interceptors). This also
means that for locals and globals we now consistently expose names
prefixed by a dollar symbol everywhere.
Drive-by-fix: Move the debug::ScopeIterator implementation for WasmFrame
into debug-wasm-support.cc, so WebAssembly scope details are all found
in one place instead of scattered around the code.
Drive-by-cleanup: Rename GetJSDebugProxy to GetWasmDebugProxy for
consistency. GetJSDebugProxy is a bit misleading, since the debug proxy
is not about JavaScript, but just exposed to JavaScript.
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1159307, chromium:1127914, chromium:1162229
Change-Id: If932bd06bbce72542823f63dac1bd976ab33937a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615348
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72009}
Previously we had introduced a special `v8::internal::WasmValue` type
which we used to expose Wasm values to the Scope view in Chromium
DevTools. The problem however is that these values cannot be exposed to
JavaScript (and in particular not to Debug Evaluate), which means that
particularly for v128 and i64 we have inconsistent representations
across the various parts of DevTools.
This change removes the `wasm` type from the RemoteObject and all the
adjacent logic, and paves the way for a uniform representation of Wasm
values throughout DevTools. For i64 we will simply use BigInt
consistently everywhere, and for i32, f32 and f64 we'll just use Number.
For externref we will represent the values as-is directly. For v128
values we currently use a Uint8Array, but will introduce a dedicated
WasmSimd128 class in a follow-up CL.
Bug: chromium:1071432
Fixed: chromium:1159402
Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71962}
The wasm-scope-info-liftoff.js and wasm-set-breakpoint-liftoff.js tests
were originally testing the Liftoff path (when we still had the Wasm
interpreter), and have received some updates along the way. Nowadays the
interpreter is going and the non-liftoff versions of these tests don't
provide any additional test coverage, but are merely a slightly less
updated version of the liftoff test.
Bug: chromium:1162229
Change-Id: Ifc9933d47f33674a83b99425ef9d0e4bc5550323
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609415
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71909}
Consistently use InspectorTest.runAsyncTestSuite() in wasm inspector
tests to make tests easier to debug (they'll fail instead of timing
out in case of errors).
Bug: chromium:1162229, chromium:1071432
Change-Id: I7aada196f9e34071aa1bb059bb45f85f75226060
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609414
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71908}
The "imports" and "exports" that were exposed on WebAssembly frames via
Debug-Evaluate aren't useful for the DWARF C/C++ extension (and likely
not for any other language extension), since they only expose static
information that's easily available (upfront) by reading the Wasm wire
bytes.
In fact, there are already standardized functions in the WebAssembly
specification, namely `WebAssembly.Module.imports(module)` and
`WebAssembly.Module.exports(module)`, which yield static information
about the imports and exports of a Wasm module.
So instead of exposing special, non-standard "imports" and "exports", we
now instead expose both the "instance" and the "module" objects via both
the Debug Proxy and the Scope view, and also add internal [[Exports]]
and [[Imports]] properties to WasmModuleObject, which under the hood use
the standard methods mentioned above.
Fixed: chromium:1162069
Bug: chromium:1071432, chromium:1083146
Screenshot: https://imgur.com/lcaW2jL.png
Doc: https://docs.google.com/document/d/1rqbu0jKTl3q_xCxLnKzkjGXWEsHnJ9aERVhKV9RNDgE#bookmark=id.925bb2qgou38
Change-Id: Ie27e55bb08ea5f90493c57375bf2b48dfb11a4d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606050
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71893}
JavaScript scopes are reported from inner-most to outer-most, while
previously we would report WebAssembly frames from outer-most to
inner-most. This is quite confusing for developers, and also doesn't
really make sense, so this CL fixes this inconsistency.
Bug: chromium:1071432
Change-Id: I6a4742f13b9a0df33e50c6fcd40992873996aaf5
Fixed: chromium:1159309
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602947
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71875}
Previously V8 would wrap the WebAssembly.Memory backing stores into
Uint8Arrays and report that as memories, but that's confusing to the
developer, since that's not what's really being used. The way that
DevTools presents the backing stores of memories, it's still perfectly
possible to get hold of an Uint8Array if that's what the developer is
looking for.
To make it possible to easily identify the WebAssembly.Memory objects
in the DevTools front-end (in particular for the memory inspector) we
add a 'webassemblymemory' subtype to the Chrome DevTools Protocol. We
also improve the description for the memories to include the number
of active pages.
Fixed: chromium:1155566
Screenshot: https://imgur.com/8enx57u.png
Change-Id: I63dbabe0e372e9ad6dcc8e6642cdb743147a620c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2574699
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71641}
Building these objects takes a lot of time and memory for realistic
applications and exposing them via the Scope view in DevTools isn't
practical either. We have a replacement in the Console now, and if
this needs more exposure we can think about other, more scalable
ways with better UX.
Fixed: v8:10986
Bug: chromium:1141781
Change-Id: I6177d63a987749889a9880cf0738031191eb5705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507696
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70894}
It makes inspector tests a lot more readable if the opcode of the pause
location is being printed. Since we already have a list of all opcodes
available in wasm-module-builder.js, we can just reuse that to build a
reverse lookup map.
This CL implements this for single-byte opcodes only, which is enough
for all tests that we currently have. It will have to be extended for
prefixed opcodes once that is being used.
R=thibaudm@chromium.org, kimanh@chromium.org
Change-Id: I085fea99d2f5f2dc6cc084448e5f7444cce5c78b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474789
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70578}
Other WebAssembly tools like wabt and wasmparser ignore empty strings
for local variable and parameter names, and just generate their own
names for it. Update V8 to comply with this convention.
Bug: chromium:1134531
Change-Id: Ic724482d93398feaf6b0797eec5a55f8ca508ca5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448457
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70305}
For now, V128 values are converted to String16 (since they are not
serializable). It is shown as a list of 16 uint8_t (hex). This
description can be tweaked as necessary.
Some updates to ARM64 required to push/pop the full Q register.
Bug: v8:10347
Bug: chromium:1130474
Change-Id: I1bffbb49f47c06da3cd26d830addae0416a4441a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422082
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70096}
This adds the wasm instance to the module scope. The instance
contains the exported entities that can now be inspected.
Bug: chromium:1043034
Change-Id: I9236ac9c126f3bc4b1e056990fe34956bbe8ed6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2213433
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67961}
Convert wasm-value into internal::WasmValue, then to debug::WasmValue.
This is then copied into a CDP protocol object via a new class,
WasmValueMirror.
Bug: v8:10347
Change-Id: I5778d2cc5701caf82e4a97ac329303e510695b74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151130
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67908}
This removes the stack from the local scope, as the stack is now
in its own scope.
Bug: chromium:1043034
Change-Id: I595604da71ecf4362ef67134ade8b3987086d258
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2128049
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67038}
This patch changes the order in which stack values are shown
in the stack scope. As a result, changes to the stack show up
at the end of the stack.
Bug: chromium:1043034
Change-Id: I735fc29d3957b6484589554ce046114e1b7bd9e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122987
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66884}
This is a minor cosmetic fix. Wasm opcodes are bytes, hence they should
always be printed as an even number of hexadecimal digits.
Note that currently we only print a single byte anyway, but in the
future we will want to extend this to correctly parse multi-byte
opcodes. Those will also be printed as an even number of characters
then.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I2423277b470d74c1c72cb619c2a43bb978423bc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122025
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66883}
This change adds a stack scope for wasm debugging.
Currently the local scope contains both local variables as well as
the expression stack. For now, this change duplicates the information
available on stacks into the stack scope, until we have added
support for the stack scope in the DevTools front-end.
Bug: chromium:1043034
Change-Id: Ib0a07e07be7c53003526a7b1e1dbfaa1116b41ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093510
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66867}
This enables the --debug-in-liftoff flag in the wasm-scope-info test.
The expected output slightly differs, because we get another breakpoint
at the end of the function body, which was actually missing before.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: Ic2628b26591763cea17403f74fe0f6d935633e6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120535
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66859}
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}
Store a flag per isolate whether new modules should be kept in
tiered-down state from the beginning. Adjust initial compilation if flag
is set.
Bug: v8:9654
Change-Id: I5aae435fb807f3eaa7efafe9af60451ad3c7e14d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028452
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66321}
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}
This fixes local names that are the string representation of a valid
element index.
Even though both the Liftoff and the interpreter-based test are changed,
only the latter needs to be fixed right now since Liftoff does not use
the names currently. Modifying the test just ensures that we implement
this correctly once we use the name.
R=jkummerow@chromium.org
Bug: v8:10019
Change-Id: Ib7f7d6e244a344a85ab540b6c2c67f98b1f3078e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1998079
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65751}
This brings the test back in sync with the wasm-scope-info-liftoff test
after the comments on https://crrev.com/c/1975754.
R=jkummerow@chromium.org
Bug: v8:10021
Change-Id: I8e3751fdb11fb32a0112c0706559a6d26e2e7594
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977860
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65723}
Inspector will no longer report per-function wasm scripts or
provide wasm disassembly. Locations in wasm are now consistently
reported through the inspector API as lineNumber=0
columnNumber=byte offset in module.
Bug: chromium:1013527, chromium:1003022
Change-Id: Ide85bbaa85ad75f29248ff82a3e7f3e40688d377
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991481
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65660}
This adds a {wasm::DebugInfo} struct which will hold the
{wasm::DebugSideTable}s for individual Liftoff functions, and will use
them to construct local scope information.
R=jkummerow@chromium.org, bmeurer@chromium.org
Bug: v8:10019
Change-Id: I7869cec5000e9b126c891a242fcccfc53c67662e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1975758
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65563}
This scenario is where user is at the end of Wasm execution and do
some stepping. Hence, user should be back at Javascript frame. We
can detect that stepping as it exits Wasm Interpreter and prepare
debugging as a step-out-ish in Javascript.
Bug: chromium:823923, chromium:1019606, chromium:1025151
Change-Id: I29022af0d5e5dcf78d87e83193f6e16fec954e87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1912985
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65122}
This is a reland of bc8ad334cd.
The CL was innocent, thus unmodified reland with TBR.
Original change's description:
> [wasm][debug] Report global scope also for compiled frames
>
> The global scope (containing global values and the memory) can be
> produced from the instance alone, hence we can also report it for
> compiled frames.
>
> R=mstarzinger@chromium.org, jgruber@chromium.org
>
> Bug: v8:9676
> Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64547}
TBR=mstarzinger@chromium.org
Bug: v8:9676
Change-Id: I2486a007156b7197d523f62ca3c30e29e7650b63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879929
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64558}
This reverts commit bc8ad334cd.
Reason for revert: breaks ASAN:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20ASAN/33137
Original change's description:
> [wasm][debug] Report global scope also for compiled frames
>
> The global scope (containing global values and the memory) can be
> produced from the instance alone, hence we can also report it for
> compiled frames.
>
> R=mstarzinger@chromium.org, jgruber@chromium.org
>
> Bug: v8:9676
> Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64547}
TBR=mstarzinger@chromium.org,jgruber@chromium.org,clemensb@chromium.org
Change-Id: I7a37723286315235f0c0a63728de58633a3b259e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878713
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64549}
The global scope (containing global values and the memory) can be
produced from the instance alone, hence we can also report it for
compiled frames.
R=mstarzinger@chromium.org, jgruber@chromium.org
Bug: v8:9676
Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64547}
This extends the scope info test to also contain a compiled frame.
Currently, no scope info is shown for this frame. This will change in
the future, and the expected output will be extended accordingly.
R=yangguo@chromium.orgCC=mstarzinger@chromium.org
Bug: v8:9676
Change-Id: Ie57c1fec5f7cbec737d40b18d091fc2d9a00f493
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876063
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64535}
These instructions were renamed in the October 2, WebAssembly CG meeting. The
issue describing the change is here:
https://github.com/WebAssembly/spec/issues/884
Change-Id: Ia9e8733156b5ed5db7fc9ab1681c1a51b874dd71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1620681
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61711}
They are added under the global scope object, as follows:
{
"memory": ...,
"globals": {
"global#0": ...,
"global#1": ...,
"global#2": ...,
}
}
We currently don't have any way to name globals in the wasm binary
format, but it is possible to extend the name section with these names
in the future.
Bug: v8:6846
Change-Id: I79fa4ed3d83964bc8e26d66516605d41e92b3d03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601829
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61425}
i64 values can be up to 20 characters long (19 + sign), plus we need
one character for the terminating null character. Thus the previous 18
needs to be increased to 21.
Also extend the test to check the longest possible i64 values.
R=ahaas@chromium.orgCC=kozyatinskiy@chromium.org
Bug: v8:8644
Change-Id: Ia9458db162a55dd57b5e8bc7cf7db73c3bab4734
Reviewed-on: https://chromium-review.googlesource.com/c/1404443
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58724}
When providing scope information (containing the value of local
variables of live stack frames), decode the local variable names of all
functions in a wasm module and store this in the WasmDebugInfo
structure.
Use these names to actually name the reported locals, instead of using
the default names "param#<d>" and "local#<d>". These names are only used
as fallbacks for locals which were not assigned a name.
R=titzer@chromium.org,kozyatinskiy@chromium.org
BUG=v8:6245
Change-Id: Ibf7d30e392248ef5590177cd8b6329239b45e018
Reviewed-on: https://chromium-review.googlesource.com/548495
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46379}
