Skip to content

V
V8
Switch branch/tag
  1. 18 Jun, 2021 1 commit
  3. 26 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][fuzzer] Fix BigInt parameters · 2d78b3a7
      Clemens Backes authored 
      The fuzzers were calling the compiled function without passing explicit
arguments. Thus all arguments were converted from the "undefined" value,
which typically results in a zero value, as expected.
For BigInt though, it's not allowed to pass "undefined". We have to pass
a proper BigInt.
This CL implements this by passing explicit parameter values for all
parameters.

This effectively unlocks testing BigInt parameters in all fuzzers, thus
may increase coverage and find new bugs.

R=ahaas@chromium.org

Bug: chromium:1120355
Change-Id: I4e451d2418eb73d460fa937d1cf95a1ab6c99cf5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377945
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69570}
      2d78b3a7
  5. 18 Aug, 2020 1 commit
    • Clemens Backes's avatar
      Reland "[wasm][fuzzer] Fix exception detection" · f7d169c6
      Clemens Backes authored 
      This is a reland of 899cb348.
The new fuzzer regression test is skipped in jitless.

Original change's description:
> [wasm][fuzzer] Fix exception detection
>
> Exceptions were detected by checking for a pending exception on the
> isolate, but {CallWasmFunctionForTesting} was clearing any pending
> exception before returning.
> This CL fixes that by explicitly passing back a boolean which is set if
> an exception occurred during execution.
>
> R=ahaas@chromium.org
>
> Bug: chromium:1115280
> Change-Id: Ife71ceef0751d18e0870335b9520c2bf77e351cc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352787
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69404}

Bug: chromium:1115280
Change-Id: I9bb7300d423c53214e51e61233b0a6b09a21fd97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361464Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69446}
      f7d169c6
  7. 14 Aug, 2020 2 commits
  9. 11 Aug, 2020 2 commits
  11. 10 Aug, 2020 2 commits
  13. 25 Jun, 2020 1 commit
  15. 23 Jun, 2020 1 commit
  17. 23 May, 2019 1 commit
  19. 22 May, 2019 1 commit
  21. 18 Apr, 2019 1 commit
  23. 20 Nov, 2018 1 commit
  25. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Store WasmModule in shared_ptr during async compilation · 6be6ec00
      Clemens Hammacher authored 
      We currently store the {WasmModule} (generated during decoding) in a
unique_ptr and pass ownership to the {WasmModuleObject} after
compilation.
I plan to move the {Managed<NativeModule>} from {WasmCompiledModule} to
{WasmModuleObject}, which will force us to create the
{WasmModuleObject} *before* compilation, so that the {CompilationState}
is available during compilation.

This CL prepares that refactoring by storing the {WasmModule} in a
{shared_ptr} in the {AsyncCompileJob}. Note that it will eventually be
stored in a {shared_ptr} in the {Managed} anyway.

R=titzer@chromium.org

Change-Id: Iac5e3c1067af2801e938f77a455a68807801526a
Reviewed-on: https://chromium-review.googlesource.com/1104117
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53801}
      6be6ec00
  27. 30 Apr, 2018 1 commit
  29. 18 Jan, 2018 1 commit
  31. 11 Oct, 2017 1 commit
  33. 07 Sep, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Avoid executing infinite loops in the wasm fuzzers · 7b53a0e0
      Andreas Haas authored 
      The wasm-async fuzzer uses the bytes provided by the fuzzer engine
directly as wasm module bytes, compiles them with async compilation, and
then tries to execute the "main" function of the module. This "main"
can have an infinite loop which causes a timeout in the fuzzer. With
this CL the "main" function is first executed with the interpreter. If
the execution in the interpreter finishes within 16k steps, which means
that there is no infinite loop, also the compiled code is executed.

I added the raw fuzzer input as a test case because in this case I
really want to test the fuzzer and not V8.

R=clemensh@chromium.org

Bug: chromium:761784
Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
Reviewed-on: https://chromium-review.googlesource.com/651046
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47874}
      7b53a0e0
  35. 18 Jul, 2017 1 commit
  37. 29 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Use pending exceptions consistently · d6aed443
      Clemens Hammacher authored 
      In our internal code, we should only use pending exceptions. They will
be converted to scheduled exceptions on the API boundary.
Hence, the ErrorThrower just sets a pending exception; it should never
have to think about scheduled exceptions. The new
ScheduledErrorThrower inherits from ErrorThrower and reschedules any
pending exceptions in its destructor (turning them into scheduled
exceptions).
In some situations, there might already be a scheduled exception, e.g.
when calling other API methods (v8::Value::Get). In this case, the
ErrorThrower should also not set another pending exception. For the
reasons mentioned above, this can only be handled in the
ScheduledErrorThrower, which is used the API methods.

This fixes one DCHECK failure and one TODO about scheduled exceptions
if no instance can be created, because the start function throws.

R=mtrofin@chromium.org, mstarzinger@chromium.org
BUG=v8:6232,chromium:736256

Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
Reviewed-on: https://chromium-review.googlesource.com/548641
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46314}
      d6aed443
  39. 21 Jun, 2017 1 commit
  41. 12 Jun, 2017 3 commits
  43. 08 May, 2017 1 commit
  45. 27 Jan, 2017 1 commit
  47. 30 Nov, 2016 1 commit
    • clemensh's avatar
      [wasm] Remove raw byte pointers from WasmModule · 6572b562
      clemensh authored 
      These byte pointers (module_start and module_end) were only valid
during decoding. During instantiation or execution, they can get
invalidated by garbage collection.
This CL removes them from the WasmModule struct, and introduces a new
ModuleStorage struct as interface to the wasm wire bytes.
Since the storage is often needed together with the ModuleEnv, a new
ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage.
The pointers in the ModuleStorage should never escape the live range of
this struct, as they might point into a SeqOneByteString or ArrayBuffer.
Therefore, the WasmInterpreter needs to create its own copy of the
whole module.
Runtime functions that previously used the raw pointers in WasmModule
(leading to memory errors) now have to use the SeqOneByteString in the
WasmCompiledModule.

R=titzer@chromium.org
BUG=chromium:669518

Review-Url: https://codereview.chromium.org/2540133002
Cr-Commit-Position: refs/heads/master@{#41388}
      6572b562
  49. 16 Nov, 2016 1 commit
  51. 14 Nov, 2016 1 commit
  53. 20 Oct, 2016 1 commit
    • ahaas's avatar
      [wasm] Track in the interpreter if a NaN could have been produced. · 57b14b06
      ahaas authored 
      The wasm specification does not fully specify the binary representation
of NaN: the sign bit can be non-deterministic. The wasm-code fuzzer
found a test case where the wasm interpreter and the compiled code
produce a different sign bit for a NaN, and as a consequence they
produce different results.

With this CL the interpreter tracks whether it executed an instruction
which can produce a NaN, which are div and sqrt instructions. The
fuzzer uses this information and compares the result of the interpreter
with the result of the compiled code only if there was no instruction
which could have produced a NaN.

R=titzer@chromium.org

TEST=cctest/test-run-wasm-interpreter/TestMayProduceNaN
BUG=chromium:657481

Review-Url: https://chromiumcodereview.appspot.com/2438603003
Cr-Commit-Position: refs/heads/master@{#40474}
      57b14b06
  55. 19 Oct, 2016 1 commit
    • titzer's avatar
      [wasm] Use a Managed<WasmModule> to hold metadata about modules. · 418b239f
      titzer authored 
      This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.

This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.

Additionally, this CL implements the proper base + offset initialization
behavior for tables.

R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316

Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}
      418b239f
  57. 13 Oct, 2016 1 commit
  59. 28 Sep, 2016 1 commit
  61. 20 Sep, 2016 1 commit
  63. 17 Sep, 2016 1 commit
    • gdeepti's avatar
      [wasm] Fix test-run-wasm-module tests in debug mode. · dd3b14b7
      gdeepti authored 
      test-run-wasm-module cctests broken in debug since recent refactoring changes for moving Compilation/Instantiation off the module object (https://codereview.chromium.org/2320723005). The problem here is that SetupIsolateForWasm tries to add the same property to a module_object multiple times and hits a DCHECK when this property is found on a lookup.
 - Fixed to use the setup method only once when CcTest::InitIsolateOnce is used.
 - Move setup method to test as this is only used for cctests/fuzzers. The install method should take care of this in the regular JS pipeline.

 R=mtrofin@chromium.org, ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2342263002
Cr-Commit-Position: refs/heads/master@{#39484}
      dd3b14b7
  65. 15 Sep, 2016 1 commit
  67. 14 Sep, 2016 1 commit
  69. 12 Sep, 2016 1 commit
    • mtrofin's avatar
      [wasm] Compilation/Instantiation pipeline works off module object · 8e5ac62d
      mtrofin authored 
      Moved the compilation/instantiation pipeline to work off the
module object (JSObject), making the compiled module data (the
FixedArray) an implementation detail. This:
- simplifies the code by removing duplicate decode->compile->instantiate
sequences
- sets up the stage for "dressing up" the runtime model with
stronger typed APIs
- helps relanding this CL: https://codereview.chromium.org/2305903002/.
  It turns out that GCs during the cloning/instantiation events cause
trouble, and centering the source of truth on the module object helps
address this issue.

In the process, clarified cctest setup for wasm-capable isolates,
and changed signatures for consistency (using ModuleOrigin througout).

BUG=

Review-Url: https://codereview.chromium.org/2320723005
Cr-Commit-Position: refs/heads/master@{#39360}
      8e5ac62d