js shell: improve propagation of wasm-specific command line arguments to child processes
Categories
(Core :: JavaScript: WebAssembly, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | fixed |
People
(Reporter: jseward, Assigned: jseward)
References
Details
Attachments
(1 file, 2 obsolete files)
In some circumstances, the JS shell may create a child process to perform wasm
compilation. It can happen that the child process chooses a different
compiler than the parent, and/or possibly that the child allows different wasm
extensions than the parent. This happens because command line arguments that
select such compilers or extensions are not propagated to the child, when they
should be.
On aarch64-linux, a debug build of the shell will fail with
Assertion failure: wasm::CodeCachingAvailable(cx), at js/src/shell/js.cpp:6762
given
../src/jit-test/jit_test.py \
--args="--wasm-compiler=ion" -f -t 60 ./dist/bin/js wasm/caching.js
due to --wasm-compiler=ion
not being propagated to the child.
Assignee | ||
Comment 1•4 years ago
|
||
In some circumstances, the JS shell may create a child process to perform wasm
compilation. It can happen that the child process chooses a different
compiler than the parent, and/or possibly that the child allows different wasm
extensions than the parent. This happens because command line arguments that
select such compilers or extensions are not propagated to the child, when they
should be. This has been observed to lead to an assertion failure.
This patch ensures propagation of the following flags:
--wasm-gc
--wasm-simd-wormhole
--wasm-exceptions
--wasm-function-references
--no-wasm-simd
--no-wasm-reftypes
--no-wasm-multi-value
--test-wasm-await-tier2
--wasm-force-ion
--disable-wasm-huge-memory
is already propagated.
It also moves propagation of the following down, so that all of the flag
propagation logic is together, at the end of main()
.
--no-sse3
--no-ssse3
--no-sse41
--no-sse42
--enable-avx
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
In some circumstances, the JS shell may create a child process to perform wasm
compilation. It can happen that the child process chooses a different
compiler than the parent, and/or possibly that the child allows different wasm
extensions than the parent. This happens because command line arguments that
select such compilers or extensions are not propagated to the child, when they
should be. This has been observed to lead to an assertion failure.
This patch ensures propagation of the following flags:
--wasm-gc
--wasm-simd-wormhole
--wasm-exceptions
--wasm-function-references
--no-wasm-simd
--no-wasm-reftypes
--no-wasm-multi-value
--test-wasm-await-tier2
--wasm-force-ion
--disable-wasm-huge-memory
is already propagated.
It also moves propagation of the following down, so that all of the flag
propagation logic is together, at the end of main()
.
--no-sse3
--no-ssse3
--no-sse41
--no-sse42
--enable-avx
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
In some circumstances, the JS shell may create a child process to perform wasm
compilation. It can happen that the child process chooses a different
compiler than the parent, and/or possibly that the child allows different wasm
extensions than the parent. This happens because command line arguments that
select such compilers or extensions are not propagated to the child, when they
should be. This has been observed to lead to an assertion failure.
This patch ensures propagation of the following flags:
--wasm-gc
--wasm-simd-wormhole
--wasm-exceptions
--wasm-function-references
--no-wasm-simd
--no-wasm-reftypes
--no-wasm-multi-value
--test-wasm-await-tier2
--wasm-force-ion
--disable-wasm-huge-memory
is already propagated.
It also moves propagation of the following down, so that all of the flag
propagation logic is together, at the end of main()
.
--no-sse3
--no-ssse3
--no-sse41
--no-sse42
--enable-avx
Comment 5•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Description
•