1. 20 May, 2021 1 commit
  2. 09 Apr, 2021 1 commit
  3. 17 Mar, 2021 1 commit
  4. 15 Mar, 2021 2 commits
  5. 05 Mar, 2021 1 commit
  6. 12 Feb, 2021 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Implement instrumentation breakpoints · 15f3392a
      Clemens Backes authored
      This CL adds support for instrumentation breakpoints in wasm. The
      request for "break on entry" is set on the script, and we need to keep
      it stored there because there might not be any instances of that wasm
      module yet. Once instances get created, the flag value is transferred to
      all instances. The flag stored there is then checked in the function
      prologue in Liftoff debugging code. This ensures that we will stop at
      the first valid break position in any function within that module.
      Hitting that instrumentation breakpoint will then clear the flag from
      the script and from all other live instances (in the same isolate).
      
      A first basic test is contained in this CL. More tests will be added
      later.
      
      R=thibaudm@chromium.org, bmeurer@chromium.org
      
      Bug: chromium:1151211
      Change-Id: I5442d4044934988269becececc03699b850d51d7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690588Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72701}
      15f3392a
  7. 09 Feb, 2021 1 commit
  8. 12 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector][wasm] Improve Scope view and instance preview. · a23adbbc
      Benedikt Meurer authored
      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/+/2622912Reviewed-by: 's avatarPhilip 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}
      a23adbbc
  9. 08 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Remove special wasm RemoteObject type. · cde7a77e
      Benedikt Meurer authored
      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/+/2614428Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarYang 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}
      cde7a77e
  10. 29 Dec, 2020 1 commit
    • Benedikt Meurer's avatar
      [wasm][debug] Expose instance and module instead of imports / exports. · ad42f966
      Benedikt Meurer authored
      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: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71893}
      ad42f966
  11. 07 Dec, 2020 1 commit
    • Benedikt Meurer's avatar
      [wasm] Use WebAssembly.Memory objects in the scope chain. · 058299a8
      Benedikt Meurer authored
      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/+/2574699Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarYang 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}
      058299a8
  12. 26 Nov, 2020 1 commit
  13. 25 Nov, 2020 1 commit
  14. 16 Oct, 2020 1 commit
  15. 16 Jun, 2020 1 commit
  16. 10 Jun, 2020 1 commit