1. 22 Jul, 2022 1 commit
    • Jakob Kummerow's avatar
      [wasm][devtools] Fix reported function body offsets · d180d40d
      Jakob Kummerow authored
      The DevTools frontend doesn't want the Wasm module's understanding of
      function body offsets (i.e. including locals), but the ranges of
      offsets where breakpoints can be set (i.e. only where instructions are).
      This patch adjusts the reported offsets accordingly.
      A consequence is that we have to report full (start,end) pairs for each
      function, instead of being able to dedupe end1==start2 etc.
      
      Bug: v8:12917
      Change-Id: I0c7d2d96435cdac2c4553647b7bcc8783bc1798b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780526
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarPhilip Pfaffe <pfaffe@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81887}
      d180d40d
  2. 19 Jul, 2022 1 commit
  3. 15 Jun, 2022 1 commit
    • Simon Zünd's avatar
      Reland "[inspector] Allow Debugger.setScriptSource to edit top-most function" · 21fe5e0f
      Simon Zünd authored
      This is a reland of commit dac61556
      
      This is a straight-up reland with no changes, because:
        1) The failure doesn't reproduce locally
        2) The failing flaky test that triggered the revert is not related
           to the code modified by this CL and should (in theory) not be
           impacted.
      
      Original change's description:
      > [inspector] Allow Debugger.setScriptSource to edit top-most function
      >
      > This CL adds a new boolean flag on the Debugger.setScriptSource CDP
      > method that gets piped all the way through to the live-edit mechanism.
      > The new flag enables live-editing of the top-most function while
      > paused.
      >
      > The CL adds a couple of tests that cover the new core use cases for
      > this flag.
      >
      > R=jarin@chromium.org
      >
      > Bug: chromium:1334484
      > Change-Id: I12fec591b2b6550d89748714620e629548e1b9c1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695354
      > Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#81127}
      
      Bug: chromium:1334484
      Change-Id: I9a9bf7e03d81c86adb4819b9756dd9afcf6fa021
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3706398Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81171}
      21fe5e0f
  4. 14 Jun, 2022 2 commits
  5. 09 Jun, 2022 1 commit
    • Simon Zünd's avatar
      [inspector] Introduce status result for Debugger.setScriptSource · 31850be1
      Simon Zünd authored
      This CL introduces a new `status` enum returned by setScriptSource.
      We'll use the information in the DevTools frontend to show more
      meaningful error messages as well as disambiguate compilation errors
      from failed live edits.
      
      Drive-by: Deprecate the sync and async stack traces in the result.
      Currently `setScriptSource` is guaranteed to stay paused so there
      is no need to send along the same information from the
      preceeding `Debugger.paused` event.
      In the future we will restart the top-most frame once we allow
      the top-most frame to be edited. In that case the inspector
      fires Debugger.resumed + Debugger.paused events following the
      live edit also making the info returned here superfluous.
      
      R=jarin@chromium.org
      
      Bug: chromium:1334484
      Change-Id: I4226491caed72013a00927273c523213d797a766
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3691850
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81031}
      31850be1
  6. 14 May, 2022 1 commit
    • Simon Zünd's avatar
      Reland "[inspector] Re-enable Debugger#restartFrame" · 9ca7491b
      Simon Zünd authored
      This is a reland of commit 8278cb50
      
      The reland adds the RestartFrameTrampoline to the list of
      builtins that the deoptimizer is allowed to return from for
      control flow integrity.
      
      Original change's description:
      > [inspector] Re-enable Debugger#restartFrame
      >
      > Doc: https://bit.ly/revive-restart-frame
      >
      > This CL "undeprecates" Debugger#restartFrame and adds a new optional
      > "mode" parameter for back-wards compatibility. Moreover, the return
      > values are all deprecated. They were never actually used in the
      > DevTools frontend and the same information is available from the
      > Debugger#paused event that fires once execution stops at the
      > beginning of the restarted function.
      >
      > The CL also re-baselines all the restart-frame inspector tests that
      > now run successfully.
      >
      > R=bmeurer@chromium.org, kimanh@chromium.org
      >
      > Bug: chromium:1303521
      > Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80491}
      
      Bug: chromium:1303521
      Change-Id: I13e2f8b5011795a38e541310622b8333a3d08049
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644624Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80534}
      9ca7491b
  7. 12 May, 2022 2 commits
  8. 10 May, 2022 1 commit
  9. 03 May, 2022 1 commit
  10. 02 May, 2022 1 commit
  11. 20 Apr, 2022 1 commit
    • Simon Zünd's avatar
      [inspector] Add 'canBeRestarted' flag to CallFrames when debugger pauses · ec41a70e
      Simon Zünd authored
      Doc: https://bit.ly/revive-restart-frame
      Context: https://crrev.com/c/3582395 (whole feature)
      
      This CL adds a new optional flag `canBeRestarted` to every call frame
      in Debugger.paused events. As the name suggests, the flag indicates
      whether we can restart a particular frame through Debugger.restartFrame
      once implemented.
      
      We are not able to safely restart all frames:
        * We don't support WASM frames
        * We don't support frames where resumable functions (async fns,
          generators) and embedder C++ frames are between the top-most
          frame and the to-be-restarted frame.
      
      Note that from a CDP perspective the flag doesn't actually guarantee
      a successful restart. CDP clients can issue
      CDP commands between the Debugger.paused event and before a user
      decides to restart a frame, which can potentially mess
      with the stack.
      
      The `canBeRestarted` flag tests are folded into the
      Debugger.restartFrame tests. As the feature is not yet fully
      implemented we short-circuit most of the tests for now and only
      run them up until the first Debugger.restartFrame call fails
      (except "fails-for-resumables.js").
      This means the tests exercise the `canBeRestarted` flag, but not
      the restarting functionality itself.
      
      R=bmeurer@chromium.org, kimanh@chromium.org
      
      Bug: chromium:1303521
      Change-Id: I01ab46dc3557ab8383960969fbe03e00604cc5e2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596160Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80046}
      ec41a70e
  12. 11 Apr, 2022 1 commit
    • Maksim Sadym's avatar
      Add `WebDriverBiDi` serialization to CDP · a913a75b
      Maksim Sadym authored
      1. Added `generateWebDriverValue` flag to `Runtime.evaluate` and `Runtime.callFunctionOn`.
      2. Added `webDriverValue` field to `RemoteObject`, and set it in case of the `generateWebDriverValue` flag was set.
      3. Added virtual method `bidiSerialize` to allow embedder-implemented serialization (like in https://crrev.com/c/3472491).
      4. Implemented V8 serialization in a separate class `V8WebDriverSerializer`.
      5. Hardcode `max_depth=1`.
      6. Added tests.
      
      Not implemented yet:
      1. `objectId`.
      2. Test of embedder-implemented serialization.
      
      Tested automatically by:
      ```
      python3 tools/run-tests.py --outdir out/foo inspector/runtime/add-web-driver-value
      ```
      
      Naming to be discussed. Suggestions are very welcome.
      
      Design doc: http://go/bidi-serialization
      
      Change-Id: Ib35ed8ff58e40b3304423cc2139050136d844e2c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472077Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Maksim Sadym <sadym@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79922}
      a913a75b
  13. 19 Jan, 2022 1 commit
    • Simon Zünd's avatar
      [inspector] Add Runtime#getExceptionDetails CDP method · 1f53cbf1
      Simon Zünd authored
      CDP has a "ExceptionDetails" structure that is attached to various
      CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
      The stack trace in the "ExceptionDetails" structure is used in
      various places in DevTools. The information in the "ExceptionDetails"
      structure is extracted from a v8::Message object. Message objects
      are normally created at the exception throw site and may augment
      the error with manually inspecting the stack (both to capture a fresh
      stack trace in some cases, as well as to calculate location info).
      
      The problem is that in some cases we want to get an "ExceptionDetails"
      structure after the fact, e.g. when logging a JS "Error" object in
      a catch block. To help in this case, this CL introduces a new
      CDP method "Runtime#getExceptionDetails" that behaves exactly as
      advertised: It provides a populated "ExceptionDetails" structure
      from a JS Error object.
      
      R=bmeurer@chromium.org
      
      Doc: https://bit.ly/runtime-get-exception-details
      Bug: chromium:1278650
      Change-Id: I084be10c1d852d3b7cac8d88e7f820e867be4722
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337258
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78676}
      1f53cbf1
  14. 16 Dec, 2021 1 commit
  15. 18 Aug, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Add nonIndexedPropertiesOnly to Runtime.getProperties. · ffa4cda6
      Benedikt Meurer authored
      This introduces a new, optional `nonIndexedPropertiesOnly` flag to the
      `Runtime.getProperties` inspector request, which tells the inspector to
      only report properties whose name is not an (typed) array index. This is
      to support retrieving all properties except for the indexed ones when
      the DevTools front-end decides to use the array bucketing mechanism.
      Previously the DevTools front-end had some quite complicated logic in
      place to simulate this via injected JavaScript, but that logic didn't
      pick up internal properties and was also interfering with the inherited
      accessor mechanism. With this new flag, it's straight-forward to
      implement the correct behavior in the DevTools front-end.
      
      The corresponding devtools-frontend CL is https://crrev.com/c/3099011.
      
      Before: https://imgur.com/hMX6vaV.png
      After: https://imgur.com/MGgiuJQ.png
      Bug: chromium:1199701
      Change-Id: Iacbe9756ed8a2e6982efaebe1e7c606d37c05379
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099686
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPhilip Pfaffe <pfaffe@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76360}
      ffa4cda6
  16. 16 Aug, 2021 1 commit
    • Camillo Bruni's avatar
      Revert "[DevTools] Implemented DevTools protocol API to retrieve V8 RunTime Call Stats." · a016cce5
      Camillo Bruni authored
      This reverts commit 91c8be95.
      
      RCS should not be exposed through the API or the inspector protocol as
      they are meant as an internal debugging feature.
      The only regularly tested and supported way is through chrome-tracing.
      
      Given that this was used mostly for an experiment to analyse chrome's
      performance, we can use pprof support as a replacement.
      
      Original change's description:
      > [DevTools] Implemented DevTools protocol API to retrieve V8 RunTime Call Stats.
      >
      > The new APIs are:
      > enableRuntimeCallStats
      > disableRuntimeCallStats
      > getRuntimeCallStats
      >
      > The RunTime Call Stats are collected per isolate.
      >
      > Change-Id: I7e520e2c866288aa9f9dc74f12572abedf0d3ac8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881601
      > Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64784}
      
      Change-Id: Ia7575436e97d3420dd7e68414d89477e6a86bb05
      Bug: v8:11395
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998585Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76297}
      a016cce5
  17. 23 Jul, 2021 1 commit
  18. 05 Jul, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Add `throwOnSideEffect` to `Runtime.callFunctionOn`. · 32328edd
      Benedikt Meurer authored
      In order to implement eager (side effect free) evaluation of arbitrary
      accessor properties correctly, we need the ability to call getters while
      guaranteeing that we don't trigger side effects. This is accomplished by
      adding a `throwOnSideEffect` flag to the `Runtime.callFunctionOn` API,
      similar to what's already available with the `Runtime.evaluate` and the
      `Debugger.evaluateOnCallFrame` APIs.
      
      Bug: chromium:1076820, chromium:1119900, chromium:1222114
      Change-Id: If2d6c51376669cbc71a9dd3c79403d24d62aee43
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001360
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75556}
      32328edd
  19. 17 Jun, 2021 1 commit
  20. 02 Jun, 2021 1 commit
  21. 27 May, 2021 1 commit
  22. 29 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debugger] Remove "Restart frame" feature. · 93f85699
      Benedikt Meurer authored
      The "Restart frame" feature was implemented as part of LiveEdit and
      primarily used to support LiveEdit of active functions, but that was
      previously disabled as part of https://crrev.com/c/2846892 because it's
      too brittle and causes crashes when using seemingly unrelated features.
      The "Restart frame" feature was also available as a context menu item
      separately in the DevTools front-end, but that was also already removed
      as part of https://crrev.com/c/2854681 earlier. So all uses are gone
      now.
      
      This change works by marking Debugger.restartFrame as deprecated and
      having it respond with a ServerError all the time. It thus allows us to
      remove a whole bunch of machinery that was essentially just put in
      various places to support the restart_fp_ magic. In particular the
      debugger no longer needs any machine specific builtins now.
      
      Bug: chromium:1195927
      Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
      Fixed: chromium:1203606
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74276}
      93f85699
  23. 23 Apr, 2021 1 commit
  24. 16 Apr, 2021 1 commit
  25. 11 Feb, 2021 1 commit
  26. 09 Feb, 2021 1 commit
  27. 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
  28. 07 Jan, 2021 1 commit
  29. 28 Dec, 2020 1 commit
    • Benedikt Meurer's avatar
      [inspector][wasm] Remove obsolete Debugger.executeWasmEvaluator(). · 39645430
      Benedikt Meurer authored
      With https://crrev.com/c/2087396 we introduced a new CDP method
      `Debugger.executeWasmEvaluator()`, which we originally intended
      to use as the foundation for Debug-Evaluate on Wasm frames.
      
      However in the process of prototyping we learned that it is too
      costly and too inefficient to use WebAssembly modules here, and
      we switched to regular Debug-Evaluate with JavaScript instead
      (with a special debug proxy exposed that allows JavaScript to
      peak into the Wasm frame), since JavaScript is better suited
      for short-lived / short-running snippets and we don't need
      clang and wasm-ld then to generate these snippets.
      
      The JavaScript exposed debug proxy (as described in [1]) not
      only enables more powerful and flexible Debug-Evaluate for the
      DWARF C/C++ extension, but also serves as the basis for various
      aspects of the Basic Wasm Developer Experience.
      
      In order to pay down technical debt and to keep the maintenance
      overhead low, we should remove the initial prototype now, also
      to ensure that we don't accidentally attract other users of CDP
      to rely on this unsupported API (despite it being marked as
      "experimental").
      
      [1]: https://docs.google.com/document/d/1VZOJrU2VsqOZe3IUzbwQWQQSZwgGySsm5119Ust1gUA
      
      Fixed: chromium:1162062
      Bug: chromium:1020120, chromium:1068571, chromium:1127914
      Change-Id: I6dba8c906a8675ce6c29a52e3c32bb6626a27247
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605186
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71882}
      39645430
  30. 23 Dec, 2020 1 commit
  31. 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
  32. 13 Nov, 2020 1 commit
  33. 01 Oct, 2020 1 commit
    • Andrey Kosyakov's avatar
      DevTools: add support for injecting bindings by context name · abacd4c1
      Andrey Kosyakov authored
      This adds support for injecting binding into contexts other than
      main based on the context name (AKA isolated world name in Blink
      terms). This would simplify a common use case for addBinding in
      Puppeteer and other automation tools that use addBinding to expose
      a back-channel for extension code running in an isolated world by
      making bindings available to such code at an early stage and in a
      race-free manner (currently, we can only inject a binding into
      specific context after the creation of the context has been reported
      to the client, which typically introduces a race with other evals
      the client may be running in the context).
      
      Change-Id: I66454954491a47a0c9aa4864f0aace4da2e67d3a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440984Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarPavel Feldman <pfeldman@chromium.org>
      Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70266}
      abacd4c1
  34. 08 Sep, 2020 1 commit
  35. 04 Aug, 2020 1 commit
  36. 27 Jul, 2020 1 commit
  37. 19 Jun, 2020 1 commit
  38. 09 Jun, 2020 1 commit