| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
When the fuzzer sees an imported segment, it makes it non-imported
(because imported ones would trap when we tried to run them: we don't
have the normal runtime they expect). We had hardcoded i32 offets there,
which need to be generalized.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds two new imports to fuzzer modules:
* call-export, which gets an export index and calls it.
* call-export-catch, which does the call in a try-catch, swallowing
any error, and returning 1 if it saw an error.
The former gives us calls back into the wasm, possibly making various
trips between wasm and JS in interesting ways. The latter adds a
try-catch which helps fuzz wasm EH.
We do these calls using a wasm export index, i.e., the index in
the list of exports. This is simple, but it does have the downside that
it makes executing the wasm sensitive to changes in exports (e.g.
wasm-merge adds more), which requires some handling in the fuzzer.
|
| |
|
| |
See https://github.com/WebAssembly/memory64/pull/92
|
| |
|
|
| |
`ModuleUtils::copyTable` was not copying the `indexType` property.
|
| |
|
|
|
|
|
| |
* Remove the code that prevented fuzzing wasm64 test files.
* Ignore a run that hits the V8 implementation limit on memory size.
* Disable wasm64 fuzzing in wasm2js (like almost all post-MVP features).
* Add fuzzer logic to emit a 64-bit memory sometimes.
* Fix various places in the fuzzer that assumed 32-bit indexes
|
| |
|
|
|
| |
Continues the work from #7027 which added throwing from JS, this adds
table get/set operations from JS, to further increase our coverage of
Wasm/JS interactions (the table can be used from both sides).
|
| |
|
|
|
|
|
|
|
|
|
| |
We already generated (throw ..) instructions in wasm, but it makes sense to model
throws from outside as well, as they cross the module boundary. This adds a new fuzzer
import to the generated modules, "throw", that just does a throw from JS etc.
Also be more precise about handling fuzzing-support imports in fuzz-exec: we now
check that logging functions start with "log*" and error otherwise (this check is
now needed given we have "throw", which is not logging). Also fix a minor issue
with name conflicts for logging functions by using getValidFunctionName for them,
both for logging and for throw.
|
| | |
|
| |
|
|
| |
Also make Try/TryTables with type none, and not just concrete types as
before.
|
| |
|
|
|
|
|
|
|
|
| |
Note: FP16 is a little different from F32/F64 since it can't represent
the full 2^16 integer range. 65504 is the max whole integer. This leads
to some slightly strange behavior when converting integers greater than
65504 since they become infinity.
Specified at
https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
|
| |
|
|
| |
Specified at
https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
|
| |
|
| |
Ensure the "fp16" feature is enabled for FP16 instructions.
|
| |
|
|
| |
Specified at
https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
|
| |
|
|
|
|
|
|
| |
Replace code that checked `isStruct()`, `isArray()`, etc. in sequence
with uses of `HeapType::getKind()` and switch statements. This will make
it easier to find the code that needs updating if/when we add new heap
type kinds in the future. It also makes it much easier to find code that
already needs updating to handle continuation types by grepping for
"TODO: cont".
|
| |
|
|
| |
Specified at
https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
|
| |
|
|
| |
Specified at
https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md
|
| |
|
|
|
|
|
|
|
| |
PR ##6803 proposed removing Type::isString and HeapType::isString in
favor of more explicit, verbose callsites. There was no consensus to
make this change, but it was accidentally committed as part of #6804.
Revert the accidental change, except for the useful, noncontroversial
parts, such as fixing the `isString` implementation and a few other
locations to correctly handle shared types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HeapType API has functions like `isBasic()`, `isStruct()`,
`isSignature()`, etc. to test the classification of a heap type. Many
users have to call these functions in sequence and handle all or most of
the possible classifications. When we add a new kind of heap type,
finding and updating all these sites is a manual and error-prone
process.
To make adding new heap type kinds easier, introduce a new API that
returns an enum classifying the heap type. The enum can be used in
switch statements and the compiler's exhaustiveness checker will flag
use sites that need to be updated when we add a new kind of heap type.
This commit uses the new enum internally in the type system, but
follow-on commits will add new uses and convert uses of the existing
APIs to use `getKind` instead.
|
| |
|
|
|
|
|
|
| |
Update the fuzzer to both handle shared types in initial contents and
create and use new shared types without crashing or producing invalid
modules. Since V8 does not have a complete implementation of
shared-everything-threads yet, disable fuzzing V8 when shared-everything
is enabled. To avoid losing too much coverage of V8, disable
shared-everything in the fuzzer more frequently than other features.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When creating a reference to `func`, fix the probability of choosing to
continue on to choose some function other than the last one rather than
making it depend on the number of functions. Then, do not eagerly pick
from the rest of the candidate functions. Instead, fall through to the
more general logic that will already pick a random candidate function.
Also move the logic for coming up with a concrete signature down to
where it is needed.
These simplifications will make it easier to update the code to handle
shared types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Give the type fuzzer the ability to generate shared heap types when the
shared-everything feature is enabled. It correctly ensures that shared
structs and arrays cannot reference unshared heap types, but that
unshared heap types can reference any heap type.
Update the main fuzzer so that for the time being it never uses the
shared-everything feature when generating additional heap types, so it
never generates shared types. We can lift this restriction once the main
fuzzer has been updated to properly handle shared types.
As a drive-by, fix some logic for subtracting feature sets from each
other that is used in this commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
Implement binary and text parsing and printing of shared basic heap types and
incorporate them into the type hierarchy.
To avoid the massive amount of code duplication that would be necessary if we
were to add separate enum variants for each of the shared basic heap types, use
bit 0 to indicate whether the type is shared and replace `getBasic()` with
`getBasic(Unshared)`, which clears that bit. Update all the use sites to record
whether the original type was shared and produce shared or unshared output
without code duplication.
|
| |
|
|
|
|
|
|
|
|
| |
caught it (#6626)
The DataSegment was manually added to .dataSegments, but we need to add it
using addDataSegment so the maps are updated and getDataSegment(name)
works.
Also add validation that would have caught this earlier: check that each item in
the item lists can be fetched by name.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With this PR we generate global.gets in globals, which we did not do before.
We do that by replacing makeConst (the only thing we did before, for the
contents of globals) with makeTrivial, and add code to makeTrivial to sometimes
make a global.get. When no suitable global exists, makeGlobalGet will emit a
constant, so there is no danger in trying.
Also raise the number of globals a little.
Also explicitly note the current limitation of requiring all tuple globals to contain
tuple.make and nothing else, including not global.get, and avoid adding such
invalid global.gets in tuple globals in the fuzzer.
|
| |
|
|
|
|
| |
The stringref proposal has been superseded by the imported JS strings proposal,
but the former has many more operations than the latter. To reduce complexity,
remove all operations that are part of stringref but not part of imported
strings.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stringview types from the stringref proposal have three irregularities that
break common invariants and require pervasive special casing to handle properly:
they are supertypes of `none` but not subtypes of `any`, they cannot be the
targets of casts, and they cannot be used to construct nullable references. At
the same time, the stringref proposal has been superseded by the imported
strings proposal, which does not have these irregularities. The cost of
maintaing and improving our support for stringview types is no longer worth the
benefit of supporting them.
Simplify the code base by entirely removing the stringview types and related
instructions that do not have analogues in the imported strings proposal and do
not make sense in the absense of stringviews.
Three remaining instructions, `stringview_wtf16.get_codeunit`,
`stringview_wtf16.slice`, and `stringview_wtf16.length` take stringview operands
in the stringref proposal but cannot be removed because they lower to operations
from the imported strings proposal. These instructions are changed to take
stringref operands in Binaryen IR, and to allow a graceful upgrade path for
users of these instructions, the text and binary parsers still accept but ignore
`string.as_wtf16`, which is the instruction used to convert stringrefs to
stringviews. The binary writer emits code sequences that use scratch locals and `string.as_wtf16` to keep the output valid.
Future PRs will further align binaryen with the imported strings proposal
instead of the stringref proposal, for example by making `string` a subtype of
`extern` instead of a subtype of `any` and by removing additional instructions
that do not have analogues in the imported strings proposal.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As of
https://chromium-review.googlesource.com/c/v8/v8/+/5471674
V8 requires stringviews to be non-nullable. It might be possible to make that
change in our IR, or to remove views entirely, but for now this PR makes the
fuzzer stop emitting nullable stringviews as a workaround to allow us to fuzz
current V8.
There are still rare corner cases where this pattern is emitted, that we have
not tracked down, and so this also makes the fuzzer ignore the error for now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(#6549)
As suggested in #6434 (comment) , lower ref.cast of string views
to ref.as_non_null in binary writing. It is a simple hack that avoids the
problem of V8 not allowing them to be cast.
Add fuzzing support for the last three core string operations, after which
that problem becomes very frequent.
Also add yet another makeTrappingRefUse that was missing in that
fuzzer code.
|
| |
|
|
|
|
|
|
| |
We added string.compare late in the spec process, and forgot to add effects for it.
Unlike string.eq, it can trap.
Also use makeTrappingRefUse in recent fuzzer string generation places that I
forgot, which should reduce the amount of traps in fuzzer output.
|
| |
|
|
|
|
|
| |
A little trickier than the others due to the risk of trapping, which this
handles like the other array operations.
Also stop using immutable i16 arrays for string operations - only
mutable ones work atm.
|
| |
|
|
|
| |
Rather than compute the map of type to locals of that type once, at the
start, also update it when relevant, as we can add more locals in some
cases. This allows us to local.get from those late-added locals too.
|
| |
|
| |
Also refactor the code a little to make it easier to add this (mostly whitespace).
|
| |
|
|
|
|
|
| |
With this we emit strings spontaneously (as opposed to just getting them from
initial contents).
The relevant -ttf test has been tweaked slightly to show the impact of this
change: now there are some string.new/const in the output.
|
| |
|
|
| |
This adds fuzzing for string.new_wtf16_array and string.from_code_point. The
latter was also missing interpreter support, which this adds.
|
| |
|
|
|
|
|
| |
Previously we chose the first with a proper type, and now we start to scan from
a random index, giving later functions a chance too, so we should be emitting a
greater variety of ref.func targets.
Also remove some obsolete fuzzer TODOs.
|
| | |
|
| |
|
|
|
|
|
|
| |
This PR is part of a series that adds basic support for the typed
continuations/wasmfx proposal.
This particular PR adds cont and nocont as top and bottom types for
continuation types, completely analogous to func and nofunc for function types
(also: exn and noexn).
|
| |
|
|
| |
We only have interpreter support for wtf16, so we should not emit operations
on the other types, as the interpreter will error.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this PR we only mutated by replacing an expression with another, which
replaced all the children. With this PR we also do these two patterns:
(A
(B)
(C)
)
=> ;; keep children, replace A
(block
(drop (B))
(drop (C))
(NEW)
)
,
(D
(A
(B)
(C)
)
)
=> ;; keep A, replace it in the parent
(D
(block
(drop
(A
(B)
(C)
)
)
(NEW)
)
)
We also try to replace onto the new D (either A itself, or A's children).
|
| | |
|
| |
|
|
| |
Instead of generating exclusively ascii strings, generate empty strings and
strings containing various unicode characters and unpaired surrogates as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WTF-16, i.e. arbitrary sequences of 16-bit values, is the encoding of Java and
JavaScript strings, and using the same encoding makes the interpretation of
string operations trivial, even when accounting for non-ascii characters.
Specifically, use little-endian WTF-16.
Re-encode string constants from WTF-8 to WTF-16 in the parsers, then back to
WTF-8 in the writers. Update the constructor for string `Literal`s to interpret
the string as WTF-16 and store a sequence of WTF-16 code units, i.e. 16-bit
integers. Update `Builder::makeConstantExpression` accordingly to convert from
the new `Literal` string representation back to a WTF-16 string.
Update the interpreter to remove the logic for detecting non-ascii characters
and bailing out. The naive implementations of all the string operations are
correct now that our string encoding matches the JS string encoding.
|
| | |
|
| |
|
|
|
| |
Add `[[maybe_unused]]` to variables that are only used in assertions. In builds
without assertions enabled, these were causing compiler errors about unused
variables.
|
| |
|
|
|
|
| |
The fuzzer already had logic to remove all references to non-imported globals
from global initializers and data segment offsets, but it was missing for
element segment offsets. Add it, and also add a missing check line for the new
test that uncovered this bug as initial fuzzer input.
|
| |
|
|
|
| |
Due to a typo, the fuzzer was making externrefs when it should have been making
exnrefs. Fix that and also let eh-utils.cpp know that TryTable exists to avoid
an assertion failure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One problem was that spec testcases had exports with names that are not
valid to write as JS exports.name. For example an export with a - in the
name would end up as exports.foo-bar etc. Since #6310 that is fixed as
we do not emit such JS (we use the generic fuzz_shell.js script which iterates
over the keys in exports with exports[name]).
Also fix a few trivial fuzzer issues that initial content uncovered:
- Ignore a wat file with invalid utf-8.
- Print string literals in the same way from JS as from C++.
- Enable the stringref flag in V8.
- Remove tag imports (the same as we do for global and function and other imports).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
At the Oct hybrid CG meeting, we decided to add back `exnref`, which was
removed in 2020:
https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-10.md
The new version of the proposal reflected in the explainer:
https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md
While adding support for `exnref` in the current codebase which has all
GC subtype hierarchies, I noticed we might need `noexn` heap type for
the bottom type of `exn`. We don't have it now so I just set it to 0xff
for the moment.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the fuzzer never added gets or sets of globals from initial content. That was
an oversight, I'm pretty sure - it's just that the code that sets up the lists from which we
pick globals for gets and sets was in another place. That is, any globals in the initial
content file were never used in new random code the fuzzer generates (only new
globals the fuzzer generated were used there).
This PR allows us to use those globals, but also ignores them with some probability,
to avoid breaking patterns like "once" globals (that we want to only be used from
initial content, at least much of the time).
Also simplify the code here: we don't need isInvalidGlobal just to handle the hang
limit global, which is already handled by not being added to the lists we pick names
from anyhow.
|
