| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Test wasm2c against versions of the spec tests from before bulk-memory
and reference-types were merged (as of commit a8bcbaf in the testsuite
repo). These should be replaced with the current versions once wasm2c
supports bulk-memory and reference-types.
|
|
|
|
|
|
| |
It doesn't make sense to be able to copy Store objects around.
This would require the objects within the store to be somehow
copied over.
|
| |
|
|
|
| |
I believe this is why #1849 managed to land without detection.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On windows these functions assert when passed negative numbers.
This change is the first step in getting wasm2c running on windows. For
now the C code can be generated on windows but the generated code cannot
is not yet MSVC compatible.
Also, update run-spec-wasm2c.py so that it run on windows, although we
are still skipping all the wasm2c tests by default on windows (for now).
Also, honor the --no-compile options which is how I managed to test
this change locally.
|
| |
|
|
|
|
|
| |
Use stricter compiler settings and fix the resulting warnings.
This is precursor to landing windows compiler support for wasm2c.
See #1843.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For text validation, this means the error is always correctly reported on
the final expression in the function.
For binary validation, this means that we report the byte after the last
instruction in the function as the failure location. This is in line
with other binary validation reports. For example, for `type mismatch
in i32.add` we report the validation error at the byte *after* the add
instruction.
|
|
|
| |
Create a memory optimized free list for Refs in the interpreter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See https://github.com/WebAssembly/tool-conventions/blob/main/CodeMetadata.md for the specification.
In particular this pr implements the following:
- Parsing code metadata sections in BinaryReader, providing appropriate callbacks that a BinaryReaderDelegate can implement:
- BinaryReaderObjdump: show the sections in a human-readable form
- BinaryReaderIr: add code metadata in the IR as expressions
- Parsing code metadata annotations in text format, adding them in the IR like the BinaryReaderIR does
- Writing the code metadata present in the IR in the proper sections when converting IR to binary
- Support in wasm-decompiler for showing code metadata as comments in the pseudo-code
All the features have corresponding tests.
Support for code metadata is gated through the --enable-code-metadata feature. For reading/writing in the text format, --enable-annotations is also required.
Missing features:
Support for function-level code metadata (offset 0)
Extensive validation in validator.cc (like making sure that all metadata instances are at the same code offset of an instruction)
|
|
|
|
| |
See #1679 #1680 #1686
|
|
|
|
| |
The algorithm is made partially recursive.
|
|
|
|
|
|
|
|
|
|
|
| |
This runs and passes 5 of the 9 multi-memory tests (although
one of them, binary.wast, is a nop for wasm2c itself).
The other 4 tests would require reference types or bulk memory:
imports.wast
load.wast
memory-multi.wast
store.wast
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bulk-memory proposal changed OOB access (when loading an active
data segment) from a validation failure to an initialization-time trap,
but wasm2c wasn't checking OOB access in LOAD_DATA().
When WASM_RT_MEMCHECK_SIGNAL_HANDLER is unset, this could produce memory
corruption. When WASM_RT_MEMCHECK_SIGNAL_HANDLER is set, this led to
failure in the new "data" tests that verify that modules with zero-length
active data segments are uninstantiable if offset > mem.size.
Add an unconditional bounds-check and restore the `test/wasm2c/spec/data.txt`
test (one of the failing tests tracked at #1737).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The primary changes here are to the interpreter and how it handles
initializer expressions. With this change we model these are normal
function that we run during module initialization.
I imagine we could optimize this further by creating one long function
and encoding the `global.set`/`memory.init`/`table.init` into the
function itself, but this change seems like a good first step to make
the current tests pass.
|
|
|
|
|
| |
Now that we have C++17 we don't need our own string_view class anymore.
Depends on #1825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When data of element segment init fails we were reporting the size, but
we were unconditionally calling `Drop` for active segments which meant
they always get reported as zero sized in the error message.
This mismatch was only showing up with bulk memory enabled (since
without this we do a two phase initialization). The only test we have
for this error message was using `--disable-bulk-memory`, but not for
any good reason (most likely because of this very bug).
Also restore the comment about why we sometimes need to do a two phase
initialization for element and data segments. This comment was lost in
PR #1330 but seem important since I don't think we have any tests for
this older behaviour.
|
|
|
|
| |
Improves memory consumption since thread instances
are freed without running garbage collector.
|
|
|
| |
Fixes #1815
|
| |
|
|
|
|
|
|
|
| |
This simplifies the code for parsing imported functions
and makes it match more closely the code for parsing
non-imported functions.
Fixes: #1806
|
|
|
|
| |
Remove test/binary/bad-function-missing-end.txt which is now
covered upstream: https://github.com/WebAssembly/spec/pull/1405
|
| |
|
|
|
| |
Fixes: #1799
|
|
|
|
|
|
| |
This check should only not be done during disassembly, only
when displaying details.
Fixes: #1790
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This finishes #985. This
- replaces the old names in the tests with the new names
- drops support for the deprecated names
- renames test files to match new instruction names
I don't think dropping support for the old names will be a problem at
this point. #985 says the old names are supported for convenience but we
should remove those too at some point; that "some point" may have well
arrived given that three years have passed.
The lists of names updated are in #933, #1564, WebAssembly/spec#720.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This applies clang-format to the whole codebase.
I noticed we have .clang-format in wabt but the codebase is not very
well formatted. This kind of mass-formatting PR has fans and skeptics
because it can mess with `git blame`, but we did a similar thing in
Binaryen a few years ago (WebAssembly/binaryen#2048, which was merged in
WebAssembly/binaryen#2059) and it was not very confusing after all.
If we are ever going to format the codebase, I think it is easier to do
it in a single big PR than dozens of smaller PRs.
This is using the existing .clang-format file in this repo, which
follows the style of Chromium. If we think this does not suit the
current formatting style, we can potentially tweak .clang-format too.
For example, I noticed the current codebase puts many `case` statements
within a single line when they are short, but the current .clang-format
does not allow that.
This does not include files in src/prebuilt, because they are generated.
This also manually fixes some comment lines, because mechanically
applying clang-format to long inline comments can look weird.
I also added a clang-format check hook in the Github CI in #1683, which
I think can be less controversial, given that it only checks the diff.
---
After discussions, we ended up reverting many changes, especially
one-liner functions and switch-cases, which are too many to wrap in
`// clang-format off` and `// clang-format on`. I also considered fixing
`.clang-format` to allow those one-liners but it caused a larger churn
in other parts. So currently the codebase does not conform to
`.clang-format` 100%, but we decided it's fine.
|
| |
|
|
|
|
|
|
|
|
|
| |
The code offset fixup for the target of a `return_call` was
not being done properly due to invalid initialization of the
offset value, and due to the fixup location being put at the
wrong offset in the instruction stream.
Fixes issue #1761
|
|
|
|
|
|
|
|
| |
This requires `Type::GetName` to return to be dynamicllay created and
return `std::string` rather then a `const char*`
As this diff shows this type name is only used in textual output and
error messages so should this change should not have a effect of binary
parse time or the interpreter.
|
|
|
|
|
|
|
|
| |
This allows them to be used in headers such as `src/type.h`
which, because they are needed in common.h, cannot themselves
include `common.h`
This allows, for example, `StringPrintf` to be used in type.h
which is something I'm planning to do as a followup.
|
|
|
|
|
|
| |
In #1768, I renamed the parameter to `OnFuncRefExpr` without realizing
that there are two distinct methods in the codebase with this name. On
is the `BinaryReader` callback which takes a function index and one is
the `TypeChecker` callback which takes a function *type* (a type index).
|
|
|
|
|
|
|
|
|
|
| |
catches. NFC (#1784)
If you leave stuff on the stack at the end of an initializer
expression use the same mechanims to report the error as we
do for functions etc.
In addition, improve such errors so its more obvious what is
going on.
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#1783)
Previously we has special cases for initializer expressions (constant
expressions). This change paves the way for adding support for
extended constant expressions that support a wider range of
instructions.
This change removes twice as many lines as it adds which shows that
this simplification is probably worthwhile even without the pending
extensions.
|
|
|
|
| |
I think it was always intended to work this way but was
left as a TODO.
|
|
|
|
|
|
|
|
|
|
| |
The SharedValidator was assuming it could keep a pointer to the incoming
location of each expression longer than the scope of the function.
This assumption holds true for one of the users of SharedValidator
(src/validator.cc) but I'm working on change that adds better location
tracking to the other one in (src/interp/binary-reader-interp.cc) and in
that case its easier to pass temporary locations into the
SharedValidator that don't outlive the call.
|
| |
|
|
|
|
| |
Use `LogOpcodeType` rather than LogOpcodeBare` when the select
instruction has a type.
|
|
|
|
|
|
|
|
|
| |
Tag names are not officially part of the extended-name-section proposal
(because it only deals with naming things that are in the spec already).
However, I think its reasonable (and useful) to include these names
under a speculative subsection ID, on the basis that tags can only exist
when exceptions are enabled and that engines should ignore unknown name
types.
|
|
|
|
|
|
|
|
| |
This PR imports the spec tests from the Wasm testsuite repo and adds infrastructure to run them correctly.
* Adds test expectations for exception handling proposal spec tests.
* Adds missing tag signature matching code for import tests.
* Adds support for the `assert_exception` command used in new tests.
* Fix filename normalization for the spec test runner.
|
|
|
|
| |
In #1770 I introduced these (duplicate) checks but it turns
out neither were necessary in the final version of the patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than spocial casing them in the reader we now use the same
instruction callbacks for instruction that appear in init expressions as
instructions that appear in normal functions.
The result of this change is the validation of init expressions is pushed
further up the stack. For example, objdump will now quite happily dump
modules that use arbitrary instructions in thier init expressions even
though they are not valid. To me, this makes sense since objdump does
not do instruction validation elsewhere.
The change is pre-cursor to allowing a wider variety of instruction
to be present in init expressions.
See https://github.com/WebAssembly/extended-const
|