Skip to content

V
V8
Switch branch/tag
  1. 27 Jan, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Introduce declared_function_index helper · 4299cb69
      Clemens Backes authored 
      We often only need to store information about declared (i.e.
non-imported) functions in a wasm module. Thus we remove the number of
imported function from a function index. We do this in several places,
with different amount of checking.

This CL extracts this logic to a new {declared_function_index} helper
and uses it wherever we do this translation. This more or less
establishes the concept of "declared function index" and hopefully
prevents errors in the future.

R=jkummerow@chromium.org

Bug: chromium:1045767
Change-Id: I7e957401495a2a8cb5d2c51031f9c69fe46195d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020763
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65994}
      4299cb69
  3. 24 Jan, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Implement toString of exported functions · 003f622a
      Clemens Backes authored 
      We currently print asm.js functions converted to wasm as
"function foo() { [native code] }", even though without asm to wasm
translation we get the proper source code. This is an observable
difference that should not be, and also foozzie finds this frequently in
different variations.

This CL makes us remember the start position (position of the "function"
token) and end position (right behind the closing "}") of each function
we transform to wasm. These offsets, together with the Script that
contained the function, allows us to reconstruct the source code of the
function for the {toString()} method.

R=jkummerow@chromium.org

Bug: chromium:667678
Change-Id: If22471cad4cefdfc67f6d1b8fda85aa0eeb411bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016582
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65972}
      003f622a
  5. 22 Jan, 2020 1 commit
  7. 21 Jan, 2020 1 commit
    • Clemens Backes's avatar
      Move decoded asm.js offset table off-heap · 87f09404
      Clemens Backes authored 
      The asm.js offset table exists in two forms: Delta-encoded in a byte
array, as generated during asm translation, and decoded, for faster
lookup.
This CL moves the encoded version from the {AsmWasmData} and
{WasmModuleObject} to the {WasmModule}, and stores it off-heap in a C++
array instead of a {ByteArray}.
Also, it moves the decoded version off-heap by storing it in a C++ data
structure that makes lookup easy, instead of encoding it again in
another {ByteArray}.

This change is a nice refactoring in itself, but it also prepares adding
more information to the offset table. For reconstructing the source code
of an asm.js function, we will need to store the start and end offsets
of the whole function as well (see linked bug).

R=jkummerow@chromium.org

Bug: chromium:667678
Change-Id: I79b789c3122dd8ba803cedc6bfdcc3d4b1fa0fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011108
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65900}
      87f09404
  9. 17 Jan, 2020 1 commit
  11. 16 Jan, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Move decoded local names off-heap · c0ee1e28
      Clemens Backes authored 
      We were decoding the names of locals into a C++ data structure, and then
generated a FixedArray out of that, stored in the on-heap WasmDebugInfo.
In order to support name lookup for debugging with Liftoff, where no
WasmDebugInfo will be present, this CL refactors the C++ data structure
to allow direct lookups and stores it in the C++ DebugInfo structure.

With this CL, the names are still only used from the old
interpreter-based debugging path. A follow-up CL will then also use it
from Liftoff.

R=thibaudm@chromium.org

Bug: v8:10019
Change-Id: I1397021b5d69b9346fc26f5e83653360f428c5e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002541
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65819}
      c0ee1e28
  13. 18 Dec, 2019 1 commit
  15. 02 Dec, 2019 1 commit
  17. 05 Nov, 2019 1 commit
    • Eric Leese's avatar
      V8 Wasm locations should always be based on byte offsets · 5c23e6b5
      Eric Leese authored 
      Currently there are two ways wasm locations are represented in the
inspector. This remains unchanged for now. Also, currently there are
multiple ways location is represented within V8, with the line number
sometimes being a function index and sometimes being 0, and the column
number being a byte offset which is sometimes function relative and
sometimes module relative. With this change, the line number is never
used within V8 (it is always 0), and the column number is always a
byte offset from the beginning of the module. This simplifies
translation logic and keeps it in one place, and will simplify future
changes to wasm location representation in the inspector API.

Bug: chromium:1013527
Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64774}
      5c23e6b5
  19. 15 Oct, 2019 1 commit
  21. 08 Oct, 2019 1 commit
    • Ingvar Stepanyan's avatar
      [wasm] Pretend that DWARF section is a fake source map · 1b5f3be0
      Ingvar Stepanyan authored 
      Unfortunately, codebase contains lots of places that use one of the two
formats as an internal representation for Wasm locations:
1) {line: 0, column: byte offset within entire module}
2) {line: function index, column: byte offset within function}

These places choose these formats interchangeably and convert from one
to another depending on the presence of source map URL in Wasm.

This is not very convenient and makes it hard to add support for DWARF
which should behave just like Wasm with source maps - that is, report a
raw Wasm script instead of fake scripts per each disassembled function,
and use representation (1) instead of (2) internally.

I tried to refactor these locations and avoid checking for source map
URLs in the previous CL - https://crrev.com/c/v8/v8/+/1833688. However,
it quickly got out of hand, and updating code in one place just kept
revealing yet another that gets broken by the changes, so I made a
decision to abandon it and leave to someone who knows the codebase
better.

Instead, this CL is based on https://crrev.com/c/v8/v8/+/1809375, but,
rather than trying to integrate DWARF separately and only for supported
agents, it pretends that encountering DWARF section is the same as
encountering a `sourceMappingURL` section with fake URL "wasm://dwarf".

This ensures that Wasm with DWARF behaves exactly in the same way as
Wasm with source maps, just like we want, with minimal changes to the
codebase. The only downside is that frontends without DWARF support
won't get even a disassembled version of Wasm that contains DWARF info.
This is unfortunate, but, as per previous discussions, should be fine
given current state of Wasm debugging.

Change-Id: Ia7256075e4bfd2f407d001d02b96883d7267436e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1834341
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64157}
      1b5f3be0
  23. 25 Sep, 2019 1 commit
    • Ingvar Stepanyan's avatar
      Add support for reporting raw Wasm scripts · c7848612
      Ingvar Stepanyan authored 
      This addition will allow to experiment with parsing DWARF information from
WebAssembly on the frontend side for improved debugging.

The frontend must explicitly opt-in to this experiment by setting
`supportsWasmDwarf: true` in `Debugger.enable` params.

When this option is present, and Wasm appears to contain DWARF information
(heuristic: `.debug_info` custom section is present), V8 will not try to
disassemble and report each WebAssembly function as a separate fake script, but
instead will report Wasm module as a whole.

Note that V8 already does this when Wasm is associated with a source map.

Additionally, this CL adds a dedicated `Debugger.getWasmBytecode` command that
accepts scriptId and returns raw wire bytes of the chosen WebAssembly module.

Change-Id: I7a6e80daf8d91ffaaba04fa15688f2ba9552870f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809375
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63969}
      c7848612
  25. 18 Sep, 2019 3 commits
  27. 21 Aug, 2019 2 commits
  29. 20 Aug, 2019 2 commits
  31. 19 Jul, 2019 1 commit
  33. 24 May, 2019 1 commit
  35. 23 May, 2019 2 commits
  37. 22 May, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Cache export wrappers per signature · d56ee2e3
      Andreas Haas authored 
      Up until now, we cached export wrappers per export index. With the
anyref proposal potentially many more functions will need export
wrappers, e.g. any function that is stored in a table, and any
function accessed by the new ref.func instruction.

With this CL, we change the caching scheme an do the caching per
signature. Thereby we can guarantee that any export wrapper which
potentially exists can be stored in the cache.

For cctests which use wasm-run-utils, we don't know the size of the
cache anymore ahead of time. However, we assume that no more than
5 signatures will be used in any cctest. If this assumption is not
true, we can just adjust the number.

The cache is now accessed in all code paths where we need an export
wrapper.

Bug: chromium:962850

Change-Id: I32df60dfa7801d1e71f7d837da091f388198af1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615247
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61752}
      d56ee2e3
  39. 29 Apr, 2019 2 commits
  41. 25 Apr, 2019 1 commit
  43. 09 Apr, 2019 1 commit
  45. 03 Apr, 2019 1 commit
  47. 02 Apr, 2019 1 commit
  49. 01 Apr, 2019 2 commits
  51. 29 Mar, 2019 1 commit
  53. 21 Mar, 2019 1 commit
    • Ben Smith's avatar
      [wasm] Call through dispatch table in interpreter · 1a88414c
      Ben Smith authored 
      When running wasm tests, the interpreter previously used a static
collection of function indexes stored in WasmTable to perform
call_indirect calls internal to that module. This has the wrong behavior
if the table is changed (via WasmTableObject::Set, `table.copy`, or
`table.init`).

This CL changes the cctests to always generate an intepreter entry for
all functions, and stores those entries in the dispatch table. This
allows us to use the same execution path as for non-testing code.

The interpreter entry compiler needed to be changed to support
multi-value returns too, since a 64-bit integer return value may be
lowered to two 32-bit integer returns.

Bug: v8:9016
Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60380}
      1a88414c
  55. 18 Mar, 2019 1 commit
  57. 04 Mar, 2019 1 commit
  59. 12 Feb, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Generate code for the table.get and table.set instructions · 01dc5707
      Andreas Haas authored 
      This CL contains the following changes:
(1) Allocate memory for WasmTables in the WasmInstance.
    - We extend the WasmInstance by a FixedArray which stores
      references to the WasmTables.
(2) Rename the name of the backing store of WasmTables from `functions`
    to `elements`.
    - The name `functions` just does not fit anyref tables.
(3) Generate code with TurboFan for table.get and table.set.
(4) Extend wasm-module-builder.js to be able to generate modules with
    multiple tables.
(5) Add  mjsunit tests to test table.get and table.set.

R=mstarzinger@chromium.org

Bug: v8:7581
Change-Id: I44af4838ee7a37b394841a2f673ecae5734a4d1c
Reviewed-on: https://chromium-review.googlesource.com/c/1463519
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59529}
      01dc5707
  61. 14 Jan, 2019 1 commit
  63. 18 Dec, 2018 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Implement anyref globals · 32562e91
      Andreas Haas authored 
      This CL implements the global.get and global.set instruction for anyref
globals. This includes:

* Properly decode anyref globals.
* Add a FixedArray to WasmInstanceObject to store anyref globals.
* Initialize the FixedArray.
* Generate code for global.get and global set.

This CL does not allow to import globals yet.

R=clemensh@chromium.org

Bug: v8:7581
Change-Id: I62617409271d9b6f2253a191681189865aa1f459
Reviewed-on: https://chromium-review.googlesource.com/c/1380112Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58318}
      32562e91
  65. 11 Dec, 2018 1 commit