Skip to content

V
V8
Switch branch/tag
  1. 13 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [wasm][debug] Simplify debug name handling. · 1bd5755b
      Benedikt Meurer authored 
      This moves the logic for the debug name heuristic, which derives names
for imported and exported entities from the relevant tables, into
wasm-debug.{cc,h} and stores these maps on the DebugInfoImpl rather than
on the WasmModule.

Drive-by-fix: Also use the import table based heuristic for function
names, just like we use it for everything else.

Bug: chromium:1164305
Change-Id: I8a21e0880c680079f63e6607b5b62c788049b9e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625870
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72061}
      1bd5755b
  3. 11 Jan, 2021 1 commit
  5. 08 Jan, 2021 2 commits
    • Benedikt Meurer's avatar
      [inspector] Implement Debug Proxy API via Interceptors. · c27c167c
      Benedikt Meurer authored 
      Previously the Debug Proxy API that's exposed on Wasm frames by
Runtime.evaluateOnCallFrame() was implemented via actual JSProxy
instances. That means that all entities such as "memories", "tables",
"stack", "globals", etc. were JSProxy instances with "get" and "has"
traps. But that has a couple of down-sides:

1. In DevTools front-end, the proxies are shown as JSProxy, which is not
   very useful to developers, since they cannot interact with them nor
   can they inspect their contents. And the object preview also only
   shows "Proxy {}" for them.
2. The performance doesn't scale well, which becomes a painful
   bottleneck with larger Wasm modules that contain hundreds of
   thousands of functions or globals.
3. We cannot use the JSProxy instances in the Scope view (for the
   reasons outlined in 1.) and hence we have different logic to provide
   Scope values than values in the rest of DevTools, which led to subtle
   but annoying bugs and inconsistencies.

This also changes the "locals" implementation by querying the values
ahead of time, similar to the object exposed to the Scope view, instead
of on-demand, since the "locals" object might survive the current
debugger pause and peeking into the stack afterwards would read invalid
memory (and might even be a security issue). For being able to change
locals we need to look into a similar solution as what we have for
JavaScript locals already. The expression stack already works this way.

For performance reasons (especially scaling to huge, realistic Wasm
modules), we cache the per-instance proxies ("functions", "memories",
"tables" and "globals") on the WasmInstanceObject and reuse them (which
is safe since they have a `null` prototype and are non-extensible), and
we also cache the proxy maps (with the interceptors) on the
JSGlobalObject per native context.

Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241
Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058
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@{#71981}
      c27c167c
    • 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
  7. 05 Jan, 2021 2 commits
  9. 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
  13. 26 Nov, 2020 1 commit
  15. 25 Nov, 2020 1 commit
  17. 20 Nov, 2020 1 commit
  19. 17 Nov, 2020 1 commit
  21. 09 Nov, 2020 1 commit
  23. 30 Oct, 2020 1 commit
  25. 05 Oct, 2020 2 commits
  27. 23 Sep, 2020 1 commit
  29. 21 Sep, 2020 1 commit
  31. 14 Sep, 2020 1 commit
    • Thibaud Michaud's avatar
      [wasm][debug] Fix DebugInfo deadlock · 383c4a44
      Thibaud Michaud authored 
      Add a separate mutex for the {debug_side_tables_} field. This ensures
that we can use {GetDebugSideTableIfExists} even if {mutex_} is already
locked.

R=ahaas@chromium.org
CC=​​clemensb@chromium.org

Bug: v8:10889
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: Icb67c45aec0cf66814705b83532f4833f36738e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402879
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69888}
      383c4a44
  33. 08 Sep, 2020 1 commit
    • Thibaud Michaud's avatar
      [wasm][debug] Handle OSR edge case · d5e0d1f7
      Thibaud Michaud authored 
      When the top frame is paused at a breakpoint, and this breakpoint is
being removed or was already removed, introduce a "dead breakpoint" in
the new code. This ensures that:
- The source position for the new frame is correct, otherwise it would
just pick the source position of the previous call,
- The offset between the source position and return address is the same
in the new and old code, which is necessary for OSR to find the correct
return address.

R=clemensb@chromium.org

Bug: v8:10337
Change-Id: I400886ff14846d3973d0634592c05960c05de738
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377686
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69731}
      d5e0d1f7
  35. 12 Aug, 2020 2 commits
  37. 28 Jul, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Fix flake about missed breakpoints · dfd86b05
      Clemens Backes authored 
      If multiple isolates were involved, we did not always hit the breakpoint
reliably in all isolates.

This CL fixes this flake this via two changes:

1. Remove breakpoint info when tiering up.
   If we keep the breakpoint information, a second isolate that later
   sets the same breakpoint will see that the breakpoint already exists,
   and will not set it again, even though the code containing the
   breakpoint has been replaced at that point.
   This fixes a flake in the debug/wasm/breakpoints test.

2. Don't overwrite code with breakpoints by default "tiered down" code.
   This is achieved by introducing another state in the {ForDebugging}
   enum which marks that code contains breakpoints. Otherwise it could
   happen that two isolates start tiering down (both recompiling missing
   functions in Liftoff), one isolate finishes and immediately sets a
   breakpoint, then the other isolates finishes and overwrites the code
   with breakpoints by the usual {kForDebugging} code.
   Setting breakpoints is synchronized already, so overwriting
   breakpoint code with other breakpoint code is always safe.

R=thibaudm@chromium.org

Bug: v8:10611, v8:10359
Change-Id: I171d86b110a54f9eb5e4c3fa35108638904212e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316080
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69088}
      dfd86b05
  39. 21 Jul, 2020 2 commits
  41. 29 Jun, 2020 1 commit
  43. 24 Jun, 2020 2 commits
    • Clemens Backes's avatar
      [wasm] Make opcode properties constexpr · 852f43cd
      Clemens Backes authored 
      This allows the compiler to eliminate more unneeded branches. Since all
functions just do a lookup in a static table (either directly, or via
compiling a switch to such a lookup), they are also good candidates for
inlining, which is made possible by this change.

One DCHECK is removed instead of pulling in the inl header, which would
require more refactoring since the check is in a non-inl header.

R=thibaudm@chromium.org
TBR=jkummerow@chromium.org

Bug: v8:10576
Change-Id: If0fd25fd62c5f30b896fc67a5458a5ae475a6351
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2259944
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68508}
      852f43cd
    • Maya Lekova's avatar
      [gcmole] Enable use-after-free detection · e7606e6b
      Maya Lekova authored 
      GCMole now comes with the long forgotten use-after-free detection
enabled by default. The CL also improves error logging when test
expectations mismatch with the actual output and updates the hash
of GCMole to be used with the newly built version with enabled UAF
detection.

The CL also contains an ignore for isolate.cc due to inability to
fix a warning there and fixes a couple of UAF warnings.

Bug: v8:9680
Change-Id: I7a009ffd5f67b1b5437567691ca4235ea873de70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257236
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68505}
      e7606e6b
  45. 23 Jun, 2020 1 commit
  47. 18 Jun, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Change ValueType representation to account for new types · 52f65296
      Manos Koukoutos authored 
      Motivation:
Changes to the typed function references and gc proposals solidified
the notion of heap type, clarified nullable vs. non-nullable reference
types, and introduced rtts, which contain an integer depth field in
addition to a heap type. This required us to overhaul our ValueType
representation, which results in extensive changes.

To keep this CL "small", we do not try to implement the binary encoding
as described in the proposals, but rather devise a simpler one of our
own (see below). Also, we do not try to implement additional
functionality for the new types.

Changes:
- Introduce HeapType. Move heap types from ValueType to HeapType.
- Introduce Nullability for reference types.
- Rework ValueType helper methods.
- Introduce rtts in ValueType with an integer depth field. Include depth
  in the ValueType encoding.
- Make the constructor of ValueType private, instead expose static
  functions which explicitly state what they create.
- Change every switch statement on ValueType::Kind. Sometimes, we need
  nested switches.
- Introduce temporary constants in ValueTypeCode for nullable types,
  use them for decoding.
- In WasmGlobalObject, split 'flags' into 'raw_type' and 'is_mutable'.
- Change IsSubtypeOfRef to IsSubtypeOfHeap and implement changes in
  subtyping.
- kWasmFuncRef initializers are now non-nullable. Initializers are
  only required to be subtypes of the declared global type.
- Change tests and fuzzers as needed.

Bug: v8:7748
Change-Id: If41f783bd4128443b07e94188cea7dd53ab0bfa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247657
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68408}
      52f65296
  49. 17 Jun, 2020 1 commit
  51. 15 Jun, 2020 1 commit
  53. 09 Jun, 2020 4 commits
  55. 06 Jun, 2020 1 commit
  57. 05 Jun, 2020 2 commits
    • Clemens Backes's avatar
      [wasm][debug] Avoid recompilation for existing breakpoint · c159f097
      Clemens Backes authored 
      If multiple workers are sharing the same module, the DevTools frontend
will set the same breakpoints in all of them, but one after another.
This CL tries to avoid repeated recompilation of that function in most
cases. Only if we need special source positions for stack rewriting, we
need to compile a special version.

R=thibaudm@chromium.org

Bug: v8:10359
Change-Id: I06114d6feb2030b75dcbde91c62b822f1807ad6e
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2231339
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68213}
      c159f097
    • Clemens Backes's avatar
      [wasm][interpreter] Remove threads support · 47e501e1
      Clemens Backes authored 
      The wasm interpreter was always single-threaded, and there are no plans
to change this. Still, there was a concept of threads, but with the
hard-coded constraint that there is always exactly one of them.

In order to clean up the code, and as a preparation to remove more
unneeded functionality before moving the interpreter over to the test
directory, this CL removes the concept of threads and merges the
{ThreadImpl} class into {WasmInterpreterInternals}.

Drive-by: Remove the dead {GetFrameCount} method.

R=ahaas@chromium.org

Bug: v8:10389
Change-Id: If65cdd21b34ce8debf8ba0f24dbeacec15e0a1d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2231354Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68204}
      47e501e1
  59. 03 Jun, 2020 1 commit