| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Use --emit-target-features and --detect-features.
Rename Asyncify handler temp files (I happened to notice they overwrote other files, which was annoying.
Fixes #2831
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this, when it finds a bug all you need to do is copy-paste
a single line and it runs the reducer. To do that, it creates a
reducer script and fills it out for you. The script has all the docs
we used to print out to the console, so the console output is
more focused and concise now.
In most cases just running the single line it suggests should
work, however I found that it doesn't always. One reason is
#2831
Also add a missing sys.exit(1), without which we returned 0
despite printing out an error on a failing testcase.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't run wasm2c2wasm on large wasm files, as it can OOM the VM.
I've seen this happen on a single wasm on multiple engines, so it's not
a specific engine bug. Sticking to below-average wasm sizes seems ok.
That change means that we check if a vm can run on a per-wasm basis.
That required some refactoring as it means we may be able to run on
the "before" wasm but not the "after" one, or vice versa.
Fix a tiny nondeterminism issue with iterating on a set().
Some tiny docs improvements to the error shown when a bug is found.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This builds on recent work for deterministic reproduction of fuzzer
testcases using IDs. With that, we can remove all the old auto-reduction
code and make something very similar possible for all* things the
fuzzer script checks for.
The idea is simple: if you run the fuzzer script and it finds a bug,
it prints out the ID it found it with. If you then run
fuzz_opt.py ID
then it runs that exact testcase again, deterministically, making
all the same random choices it made before. The new addition
in this PR is that you can do
fuzz_opt.py ID WASM
which also adds a wasm file. If provided, we still randomly
generate one in the fuzzer script (so that later random numbers
are the same) but we swap in that provided wasm. This then
lets wasm-reduce drive fuzz_opt.py itself as a whole. No more
extracting a testcase and all its commands, it's all done for you.
The fuzzer script will print out hopefully-useful text when it finds
a bug, something like this:
================================================================================
You found a bug! Please report it with
seed: 4671273171120144526
and the exact version of Binaryen you found it on, plus the exact Python
version (hopefully deterministic random numbers will be identical).
You can run that testcase again with "fuzz_opt.py 4671273171120144526"
The initial wasm file used here is saved as /home/username/binaryen/out/test/original.wasm
You can try to reduce the testcase with
wasm-reduce /home/username/binaryen/out/test/original.wasm '--command=bash reduce.sh' -t /home/username/binaryen/out/test/t.wasm -w /home/username/binaryen/out/test/w.wasm
where "reduce.sh" is something like
# check the input is even a valid wasm file
bin/wasm-opt /home/username/binaryen/out/test/t.wasm
echo $?
# run the command
./scripts/fuzz_opt.py 4671273171120144526 /home/username/binaryen/out/test/t.wasm > o 2> e
cat o | tail -n 10
echo $?
You may want to adjust what is printed there: in the example we save stdout
and stderr separately and then print (so that wasm-reduce can see it) what we
think is the relevant part of that output. Make sure that includes the right
details, and preferably no more (less details allow more reduction, but raise
the risk of it reducing to something you don't quite want).
You may also need to add --timeout 5 or such if the testcase is a slow one.
================================================================================
The text has full instructions to run the reducer, which should
work in almost all cases - see (*) note below. Because of that
corner case I think it's safer to not run the reducer automatically,
but it's just a quick copy-paste away, and the user can then adjust
the reduce.sh script if necessary.
(*) Well, almost any. There are some corner cases, such as if the
fuzzer generator includes bounds checks in the wasm, reduction
might remove them. We can fix this eventually by making the
bounds checks additions a pass that can be run after the fuzzer
generator, but meanwhile you can work around this by making the
reduction script look for the right thing (i.e. if all it looks for is a
failing return code, that won't be enough as a removed bounds
check will fail but on something else).
|
| |
|
|
|
| |
Just like the parent wasm2c, with NaNs don't compare to self before
and after optimizations. The binaryen optimizer does different things than the
LLVM optimizer there, and NaN bits can change.
|
| |
|
|
|
|
| |
Avoid pass-debug when fuzzing emcc, as it can be slow and isn't
what we care about.
Clean up a loop.
|
| |
|
|
|
|
| |
These tests are now optional. However, if you run them and the
build is not found they will now error out, in order to avoid silently
failing.
|
| |
|
| |
Since the --roundtrip pass is more general than --fuzz-binary anyways. Also reimplements `ModuleUtils::clearModule` to use the module destructor and placement new to ensure that no members are missed.
|
| |
|
|
|
|
|
|
|
| |
This adds a variant on wasm2c that uses emcc instead of a
native compiler. This helps us fuzz emcc.
To make that practical, rewrite the setjmp glue to only use one
setjmp. The wasm backend ends up doing linear work per setjmp,
so it's quadratic with many setjmps. Instead, do a big switch-loop
construct around a single setjmp.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for fuzzing with wabt's wasm2c that @binji wrote.
Basically we compile the wasm to C, then compile the C to a native
executable with a custom main() to wrap around it. The executable
should then print exactly the same as that wasm when run in either
the binaryen interpreter or in a JS VM with our wrapper JS for that
wasm. In other words, compiling the wasm to C is another way to
run that wasm.
The main reasons I want this are to fuzz wasm2c itself, and to
have another option for fuzzing emcc. For the latter, we do fuzz
wasm-opt quite a lot, but that doesn't fuzz the non-wasm-opt
parts of emcc. And using wasm2c for that is nice since the
starting point is always a wasm file, which means we
can use tools like wasm-reduce and so forth, which can be
integrated with this fuzzer.
This also:
Refactors the fuzzer harness a little to make it easier to
add more "VMs" to run wasms in.
Do not autoreduce when re-running a testcase, which I hit
while developing this.
|
| |
|
|
|
|
| |
The intention is to move away from travis and appveyor which have
become very slow.
See: #2356
|
| |
|
|
|
|
|
|
|
| |
1. Only emit exnref as part of a subtype if exception-handling is
enabled in the fuzzer.
2. Correctly report that funcref and nullref require reference-types
to be enabled.
3. Re-enable multivalue as a normal feature in the fuzzer.
Possibly fixes #2770.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Emit tuple.make, tuple.extract, and multivalue control flow, and tuple locals
and globals when multivalue is enabled. Also slightly refactors the top-level
`makeConcrete` function to be more selective about what it tries to
make based on the requested type to reduce the number of trivial nodes
created because the requested type is incompatible with the requested
node.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main benefit here is comparing VMs, instead of just comparing
each VM to itself after opts. Comparing VMs is a little tricky since there
is room for nondeterminism with how results are printed and other
annoying things, which is why that didn't work well earlier.
With this PR I can run 10's of thousands of iterations without finding
any issues between v8 and the binaryen interpreter. That's after
fixing the various issues over the last few days as found by this:
#2760 #2757 #2750 #2752
Aside from that main benefit I ended up adding more improvements
to make it practical to do all that testing:
Randomize global fuzz settings like whether we allow NaNs and
out-of-bounds memory accesses. (This was necessary here since
we have to disable cross-VM comparisons if NaNs are enabled.)
Better logging of statistics like how many times each handler
was run.
Remove redundant FuzzExecImmediately handler (looks like
after past refactorings it was no longer adding any value).
Deterministic testcase handling: if you run e.g. fuzz_opt.py 42 it
will run one testcase and exactly the same one. If you run without
an argument it will run forever until it fails, and if it fails, it prints out
that ID so that you can easily reproduce it (I guess, on the same
binaryen + same python, not sure how python's deterministic
RNG changes between versions and builds).
Upgrade to Python 3.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In wasm2js we ignore things that trap in wasm that we can't
really handle, like a load from memory out of bounds would
trap in wasm, but in JS we don't want to emit a bounds check
on each load. So wasm2js focuses on programs that don't
trap.
However, this is annoying in the fuzzer as it turns out that
our behavior for places where wasm would trap was not
deterministic. That is, wasm would trap, wasm2js would not
trap and do behavior X, and wasm2js with optimizations
would also not trap but do behavior Y != X. This produced
false positives in the fuzzer (and might be annoying in
manual debugging too).
As a workaround, this adds a --deterministic flag to wasm2js,
which tries to be deterministic about what it does for cases
where wasm would trap. This handles the case of an int
division by 0 which traps in wasm but without this flag could
have different behavior in wasm2js with or without opts
(see details in the patch).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are no all driven by only by the two top level scripts:
check.py
auto_update_tests.py
What is more all of them were broken when run isolation due to
relative import rules in python3. e.g.:
```
$ scripts/test/binaryenjs.py
Traceback (most recent call last):
File "scripts/test/binaryenjs.py", line 21, in <module>
from . import shared
ImportError: cannot import name 'shared' from '__main__' (scripts/test/binaryenjs.py)
```
|
| |
|
|
| |
Also, factor out auto-updating of binaryenjs testing so it lives
alongside the actual test code.
|
| |
|
|
|
| |
It looks like these were only uses as part of the vanilla tests
which were removed back in #2482.
|
| |
|
|
|
| |
If wasm-emscripten-finalize is given the BigInt flag, then we will
be using BigInts on the JS side, and need no legalization at all
since i64s will just be BigInts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we update the dylink section properly, we can
do the same optimization in side modules as in main ones:
if the module provides a function, don't call an $fp method
during startup, instead add it to the table ourselves and use
the relative offset to the table base.
Fix an issue when the table has no segments initially: the
code just added an offset of 0, but that's not right. Instead,
an a __table_base import and use that as the offset. As
this is ABI-specific I did it on wasm-emscripten-finalize,
leaving TableUtils to just assert on having a singleton
segment.
Add a test of a wasm file with a dylink section to the lld tests.
|
| |
|
|
|
|
| |
Adds full support for the {i8x16,i16x8,i32x4}.abs instructions merged
to the SIMD proposal in https://github.com/WebAssembly/simd/pull/128
as well as the {i8x16,i16x8,i32x4}.bitmask instructions proposed in
https://github.com/WebAssembly/simd/pull/201.
|
| |
|
|
|
|
|
|
| |
Tuple operations lower to stacky code, so round tripping from IR to
binary and back is a lossy operation. To help make diagnosing bugs
uncovered by the fuzzer easier, this change writes the original IR
generated by the fuzzer and the IR produced by optimizations to files
that can be inspected after a crash to determine exactly what IR was
emitted.
|
| |
|
|
|
|
|
|
|
| |
Implements parsing and emitting of tuple creation and extraction and tuple-typed control flow for both the text and binary formats.
TODO:
- Extend Precompute/interpreter to handle tuple values
- C and JS API support/testing
- Figure out how to lower in stack IR
- Fuzzing
|
| |
|
| |
An attempt to fix the node-esm-loader related [issues](https://travis-ci.org/WebAssembly/binaryen/jobs/649056649#L22931) seen on CI currently, apparently due to CI automatically picking up a newer node LTS (12.16.0 released 2020/02/11) where the API changed.
|
| | |
|
| |
|
|
| |
fail_if_not_identical_to_file() (#2649)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds EH support to `EffectAnalyzer`. Before `throw` and `rethrow`
conservatively set property. Now `EffectAnalyzer` has a new property
`throws` to represent an expression that can throw, and expression that
can throw sets `throws` correctly.
When EH is enabled, any calls can throw too, so we cannot reorder them
with another expression with any side effects, meaning all calls should
be treated in the same way as branches when evaluating `invalidate`.
This prevents many reorderings, so this patch sets `throws` for calls
only when the exception handling features is enabled. This is also why I
passed `--disable-exception-handling` to `wasm2js` tests. Most of code
changes outside of `EffectAnalyzer` class was made in order to pass
`FeatureSet` to it.
`throws` isn't always set whenever an expression contains a throwable
instruction. When an throwable instruction is within an inner try, it
will be caught by the corresponding inner catch, so it does not set
`throws`.
|
| |
|
|
|
| |
This reverts commit 132daae1e9154782bb1afa5df80dfe7ea35f0369.
This change is the same as before but the fix in #2619 should now make it safe.
|
| |
|
|
|
|
| |
It is convenient to have the full command when debugging fuzzing errors.
The fuzzer sometimes fails before running `wasm-reduce` and being able
to reproduce the command right away from the log is very handy in that
case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Track the beginning and end of each function, both when reading
and writing.
We track expressions and functions separately, instead of having a single
big map of (oldAddr) => (newAddr) because of the potentially ambiguous case
of the final expression in a function: it's end might be identical in offset
to the end of the function. So we have two different things that map to the
same offset. However, if the context is "the end of the function" then the
updated address is the new end of the function, even if the function ends
with a different instruction now, as the old last instruction might have
moved or been optimized out. Concretely, we have getNewExprAddr
and getNewFuncAddr, so we can ask to update the location of either
an expression or a function, and use that contextual information.
This checks for the DIE tag in order to know what we are looking for.
To be safe, if we hit an unknown tag, we halt, so that we don't silently
miss things.
As the test updates show, the new things we can do thanks to this
PR are to update compile unit and subprogram low_pc locations.
Note btw that in the first test (dwarfdump_roundtrip_dwarfdump.bin.txt)
we change 5 to 0: that is correct since that test does not write out
DWARF (it intentionally has no -g), so we do not track binary
locations while writing, and so we have nothing to update to (the
other tests show actual updating).
Also fix the order in the python test runner code to show a diff
of expected to encountered, and not the reverse, which confused
me.
|
| |
|
|
|
| |
Binaryen.js now uses binaryen (was Binaryen) as its global
name to align with the npm package. Also fixes issues with
emitting and testing both the JS and Wasm builds.
|
| |
|
|
|
| |
(#2542)" (#2576)
This reverts commit f62e171c38bea14302f9b79f7941a248ea704425.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the reference type proposal. This includes support
for all reference types (`anyref`, `funcref`(=`anyfunc`), and `nullref`)
and four new instructions: `ref.null`, `ref.is_null`, `ref.func`, and
new typed `select`. This also adds subtype relationship support between
reference types.
This does not include table instructions yet. This also does not include
wasm2js support.
Fixes #2444 and fixes #2447.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Reland "Fix renaming in FixInvokeFunctionNamesWalker (#2513)"
In the previous iteration of this change we were not calling
`renameFunctions` for each of the functions we removed.
The problem manifested itself when we rename the imported function to
`emscripten_longjmp_jmpbuf` to `emscripten_longjmp`. In this case the
import of `emscripten_longjmp` already exists so we remove the import of
`emscripten_longjmp_jmpbuf` but we were not correclty calling
renameFunctions to handle the rename of all the uses.
Add an additional test case to cover the failures that we saw on the
emscripten tree.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR enables compiling Binaryen to WebAssembly when building binaryen.js. Since WebAssembly is best compiled and instantiated asynchronously in browsers, it also adds a new mechanism to tell if respectively when the module is ready by means of one of the following:
// Using a promise
const binaryen = require("binaryen");
binaryen.ready.then(() => {
... use normally ...
});
// Using await
const binaryen = require("binaryen");
(async () => {
await binaryen.ready;
... use normally ...
})();
// Where top-level await is available
const binaryen = await require("binaryen").ready;
... use normally ...
One can also tell if Binaryen is already ready (for example when assuming it in follow-up code) by:
if (/* we already know that */ binaryen.isReady) {
... use normally ...
} else {
throw Error("Binaryen is supposed to be ready here but isn't");
}
The JS test cases have been updated accordingly by wrapping everything in a test function and invoking it once ready. Documentation will have to be updated as well to cover this of course. New file size is about 2.5mb, even though the Wasm becomes inlined into the JS file which makes distribution across different environments a lot easier.
Also makes building binaryen (to either js or wasm) emit binaryen.js, and not binaryen_js.js etc.
Supersedes and thus fixes #1381
With .ready it also fixes #2452
|
| |
|
| |
This reverts commit f0a2e2c75c7bb3008f10b6edbb8dc4cfd27b7d28.
|
| |
|
| |
As specified in https://github.com/WebAssembly/simd/pull/126.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes https://github.com/emscripten-core/emscripten/issues/9950.
The issue only shows up when debug names are not present so most of
the changes in CL come from disabling debug names in the lld tests.
We want to make sure that wasm-emscripten-finalize runs fine without
debug names so I think it makes most sense to test in this mode.
The actual bugfix is in wasm-emscripten.cpp as part of the
FixInvokeFunctionNamesWalker. The problem was the name of the function
rather than is import name was being added to importRenames. This means
that when debug names were present (and the two names were the same)
we didn't see the bug.
|
| |
|
|
|
|
|
|
|
| |
In normal mode we call a JS import, but we can't import from JS
in standalone mode. Instead, just trap in that case with an
unreachable. (The error reporting is not as good in this case, but
at least it catches all errors and halts, and the emitted wasm is
valid for standalone mode.)
Helps emscripten-core/emscripten#10019
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function signatures were previously redundantly stored on Function
objects as well as on FunctionType objects. These two signature
representations had to always be kept in sync, which was error-prone
and needlessly complex. This PR takes advantage of the new ability of
Type to represent multiple value types by consolidating function
signatures as a pair of Types (params and results) stored on the
Function object.
Since there are no longer module-global named function types,
significant changes had to be made to the printing and emitting of
function types, as well as their parsing and manipulation in various
passes.
The C and JS APIs and their tests also had to be updated to remove
named function types.
|
| | |
|
| |
|
|
| |
(#2508)
|
| |
|
|
|
|
| |
This pass writes and reads the module. This shows the effects
of converting to and back from the binary format, and will be
useful in testing dwarf debug support (where we'll need to see
that writing and reading a module preserves debug info properly).
|
| | |
|
| | |
|
