Skip to content

V
V8
Switch branch/tag
  1. 24 Sep, 2021 1 commit
  3. 04 Aug, 2021 1 commit
  5. 14 Jul, 2021 1 commit
    • Benedikt Meurer's avatar
      [refactor] Introduce dedicated WasmScript::SetBreakPointOnEntry(). · 95b2f02d
      Benedikt Meurer authored 
      Previously we had passed kOnEntryBreakpointPosition as a marker through
the regular SetBreakPointForScript() logic and handled that specially in
WasmScript, however this instrumentation breakpoint is special and gets
in the way of returning more information about a regular breakpoint in
case of crbug.com/700516, so I decided to just isolate that into it's
own method, especially since the only user already special-cases Wasm
anyways.

Bug: chromium:1162229, chromium:700516
Change-Id: Ie7966c1701365a4b03710d6dc32cc8278577ee3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026711
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75724}
      95b2f02d
  7. 22 Jun, 2021 1 commit
    • Clemens Backes's avatar
      Reland "[wasm] Provide a global WasmCodeManager" · 4e19455b
      Clemens Backes authored 
      This is a reland of 0f90a2aa.
The issue was inverted destructor order between WasmCodeManager and
WasmEngine. WasmEngine has to be destructed first, because it contains
a barrier to ensure that background compile threads finished before
global state is being destructed.

Original change's description:
> [wasm] Provide a global WasmCodeManager
>
> The WasmCodeManager was part of the WasmEngine so far, but there is only
> exactly one WasmEngine. Hence we can pull it out, and also remove the
> pointer in the WasmCodeAllocator.
>
> The argument passed from the single constructor call is now inlined in
> the constructor itself.
>
> Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just
> "CommitPageSize()".
>
> R=jkummerow@chromium.org
>
> Bug: v8:11879
> Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75270}

Bug: v8:11879
Change-Id: I0eaa2395f5c1e30f3f7303c5f3df70c227b74d3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2975859
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75289}
      4e19455b
  9. 21 Jun, 2021 3 commits
  11. 18 Jun, 2021 1 commit
  13. 01 Jun, 2021 1 commit
  15. 15 Apr, 2021 1 commit
    • Thibaud Michaud's avatar
      [wasm][x64] Fix OSR shadow stack violation · 06a2c2e0
      Thibaud Michaud authored 
      We currently allow OSR (On-Stack Replacement) of arbitrarily deep return
addresses. This is in direct violation of Intel CET's shadow stack,
which we plan to enable eventually.

This change works around this by postponing OSR until after we return to
the old code. The main changes are:
- Reserve a slot in Liftoff frames to store the OSR target,
- Skip the return address modification, and instead store the new code
pointer in the dedicated slot,
- Upon returning to the old code, check the slot and do an indirect jump
to the new code if needed.

CET also prevents indirect jumps to arbitrary locations, so the last
point is also a CET violation. Valid indirect jump targets must be
marked with the ENDBRANCH instruction, which I will do in a follow-up
CL.

Bug: v8:11654
Change-Id: I6925005211aa95d60803b9409e3c07c7c226b25c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826127
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73977}
      06a2c2e0
  17. 22 Mar, 2021 2 commits
  19. 08 Mar, 2021 1 commit
  21. 05 Mar, 2021 2 commits
  23. 04 Mar, 2021 1 commit
    • Clemens Backes's avatar
      Reland "[wasm][debug] Cache debugging code" · 69d1e2c2
      Clemens Backes authored 
      This is a reland of fab754ff.
The lock-order inversion is fixed by putting the old code into the
surrounding WasmCodeRefScope such that it gets deleted only after
releasing the mutex.

Original change's description:
> [wasm][debug] Cache debugging code
>
> This adds a little cache for debugging code, including stepping code.
> Especially in stepping, we are currently repeatedly recompiling the same
> function, because whenever we pause (after every step) we clear
> stepping, only to reinstantiate it if the user continues stepping.
> Especially in source-level stepping this is wasteful, because stepping
> over a single line of C++ code can execute hundreds or thousands of
> steps in wasm.
>
> R=thibaudm@chromium.org
>
> Bug: chromium:1172299
> Change-Id: Id59a26cc67a5bf4a2d3cf6b1e8f14a8b1c73712c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732015
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73162}

Bug: chromium:1172299
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: Ic2f92e2758e78dc4912021cd17267a4da563c0a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732675Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73188}
      69d1e2c2
  25. 03 Mar, 2021 2 commits
    • Clemens Backes's avatar
      Revert "[wasm][debug] Cache debugging code" · 685f2596
      Clemens Backes authored 
      This reverts commit fab754ff.

Reason for revert: TSan failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/13875/overview

Original change's description:
> [wasm][debug] Cache debugging code
>
> This adds a little cache for debugging code, including stepping code.
> Especially in stepping, we are currently repeatedly recompiling the same
> function, because whenever we pause (after every step) we clear
> stepping, only to reinstantiate it if the user continues stepping.
> Especially in source-level stepping this is wasteful, because stepping
> over a single line of C++ code can execute hundreds or thousands of
> steps in wasm.
>
> R=​thibaudm@chromium.org
>
> Bug: chromium:1172299
> Change-Id: Id59a26cc67a5bf4a2d3cf6b1e8f14a8b1c73712c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732015
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73162}

Bug: chromium:1172299
Change-Id: I8fac7701e6f58012c8e17322c22f29692ee8932b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732020
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73168}
      685f2596
    • Clemens Backes's avatar
      [wasm][debug] Cache debugging code · fab754ff
      Clemens Backes authored 
      This adds a little cache for debugging code, including stepping code.
Especially in stepping, we are currently repeatedly recompiling the same
function, because whenever we pause (after every step) we clear
stepping, only to reinstantiate it if the user continues stepping.
Especially in source-level stepping this is wasteful, because stepping
over a single line of C++ code can execute hundreds or thousands of
steps in wasm.

R=thibaudm@chromium.org

Bug: chromium:1172299
Change-Id: Id59a26cc67a5bf4a2d3cf6b1e8f14a8b1c73712c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732015Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73162}
      fab754ff
  27. 26 Feb, 2021 1 commit
  29. 24 Feb, 2021 1 commit
  31. 22 Feb, 2021 1 commit
  33. 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
  35. 08 Feb, 2021 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Delta-encode the debug side table · 392a0251
      Clemens Backes authored 
      For functions with a very large stack, the debug side table repeats a
lot of information: Most values will be spilled to the stack, still
every single entry in the debug side table repeats information about
them (type, stack offset). This leads to the size of the debug side
table to be quadratic in the size of the function.

In the linked bug, the generation of the debug side table took ~400ms,
whereas Liftoff compilation alone just took 16ms.

This CL optimized the debug side table by delta-encoding the entries,
i.e. only storing stack slots that changed. This reduces the size of the
table significantly, at the cost of making lookup slower, since that now
has to search the table backwards for the last entry that had
information about a specific slot. For now, this seems like a good
compromise. If it turns out to be a problem, we could speed up the
lookup by either forcing a full dump of the stack state after N entries,
or by dynamically inserting new entries during lookup, whenever we find
that we had to search backwards more than N entries. That would speed up
subsequent lookups then.

On the reproducer in the linked bug, this change reduces the time to
generate the debug side table from ~400ms to ~120ms.
Before this CL, the debug side table has 13,314 entries with a total of
38,599,606 stack value entries. After this CL, it shrinks to 20,037
stack value entries in the 13,314 entries (average of ~1.5 instead of
~2,899).

R=thibaudm@chromium.org

Bug: chromium:1172299
Change-Id: Ie726bb82d4c6648cc9ebd130115ee7ab3d1d551b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676636Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72558}
      392a0251
  37. 04 Feb, 2021 1 commit
  39. 02 Feb, 2021 2 commits
  41. 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
  43. 11 Jan, 2021 1 commit
  45. 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
  47. 05 Jan, 2021 2 commits
  49. 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
  51. 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
  53. 26 Nov, 2020 1 commit
  55. 25 Nov, 2020 1 commit
  57. 20 Nov, 2020 1 commit
  59. 17 Nov, 2020 1 commit
  61. 09 Nov, 2020 1 commit
  63. 30 Oct, 2020 1 commit