- 05 Mar, 2021 1 commit
-
-
Jakob Kummerow authored
This adds support for WasmGC objects (structs/arrays) to the inspector backend. For prettier printing, it also adds support for reading the "type" and "field" subsections of the "name" section in Wasm modules. This patch includes a revert of most of commit crrev.com/987a7f4a because types are more complicated now. Bug: v8:7748, chromium:1177784 Change-Id: Icec52cbbb32291b0e773b40be6771a678c6ec79b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715193 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73212}
-
- 15 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
Also block sending "type" as part of the ObjectPreview, but only send the "value" property. The front-end will be updated to display WasmValueObject's similar to what we do for wrapper objects (i.e. StringWrapper and the like). The matching front-end change is still pending. Also refactor the WasmValueObject to have dedicated constructors for the individual types (i32, i64, f32, f64, externref and v128). This way we can just reuse the existing logic in descriptionForObject() and we also don't need to store the "type" on the object itself (not really performance sensitive, but fewer moving parts / things that can go wrong). This also addresses the crash in https://crbug.com/1166077#c16 since the WasmValueObject instances now have a proper JSFunction in their maps' constructor_or_backpointer slot and are thus able to locate their creation context. Note that this doesn't generally address https://crbug.com/1166077 itself, but only the WasmValueObject case. Screenshot: https://imgur.com/kbd3bix.png Bug: chromium:1170282, chromium:1071432 Bug: chromium:1159402, chromium:1166077 Change-Id: Iae649cad155efd774cfb1f4eea8cf406e413c03a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692574Reviewed-by: Philip Pfaffe <pfaffe@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72736}
-
- 09 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
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/+/2643384Reviewed-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}
-