| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This matches the behaviour of i32 printing.
Ref: https://github.com/WebAssembly/wabt/pull/2342
|
| | |
|
| |
|
| |
See https://github.com/llvm/llvm-project/pull/67493
|
| | |
|
| |
|
|
|
|
|
| |
The tag name subsection currently has the speculative ID of 10.
However, the extended-name-section proposal has now been updated to
use an ID of 11 for the tag name section. This updates the
NameSectionSubsection enum accordingly, as well as adding a field
name section with the ID of 10.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, attempting to read from a pipe would result in an error:
'not a regular file', disallowing use of files like /dev/stdin or
/dev/fd/3, named fifos, sockets, etc.
The tools already understand how to (try to) read from non-regular
files, so this change attempts to do so when the input is not seek-able
(the "regular file" capability that's in use here).
Additionally, this adds a test for the new behavior using a bash
herestring and process substitution (the latter of which shows up in
argv as something like `/dev/fd/NN`). Since bash isn't commonly
installed on Windows, this change also introduces a new capability to
filter tests to specific platforms (sorry).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We are seeing some (spurious?) warning from gcc 12.2.
I've been seeing them locally, but they started to show up in CI
as part of #2292.
|
| |
|
|
|
|
| |
This continues the work from #1783 and reduces special handling of elem
exprs, by treating them the same as other const expressions (init
expressions).
|
| |
|
|
|
|
|
|
|
| |
Fixes #2283
Previously, the OnSelectExpr delegate would terminate validation if the
SharedValidator found an error in the expression, or if the Validator
had previously found an error at any point in validating the module.
This commit normalizes the behavior to match how the Validator handles
other expression types.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, in BinaryReaderObjdumpDisassemble::BeginFunctionBody,
we had:
local_index_ = objdump_state_->function_param_counts[index];
where index is the index of the function i.e. we treat the keys of
function_param_counts as function indices.
However, function_param_counts is populated in OnFuncType with:
objdump_state_->function_param_counts[index] = param_count;
where index is the index of the type i.e. we treat the keys of
function_param_counts as type indices.
This discrepancy would cause the locals to be incorrectly numbered
in the "Code Disassembly" section.
This fixes the discrepancy by adding a new field, function_types,
which maps from function indices to type indices, and is populated
in BinaryReaderObjdump::OnFunction. This field is used in
BinaryReaderObjdumpDisassemble::BeginFunctionBody to get the type
index for the given function, which is then used to get the
parameter count.
Fixes #2264.
|
| |
|
| |
With memory64, the offset becomes a u64.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* memory64: when enabled, offset range check is at validation-time
Before memory64, the "offset" in a load/store expression was
a u32, and we enforced this in the WastParser and BinaryReader.
After memory64, the "offset" becomes a u64 syntactically, and the
validator checks that it's <= UINT32_MAX for i32 memories.
We hadn't been correctly allowing these very large offsets
in the text format (even when memory64 was enabled and the memory
was i64).
(This change also eliminates the "memories" member in the
BinaryReader. The BinaryReader no longer needs to keep track
of the memories and their types to check well-formedness.)
|
| |
|
|
|
|
| |
Previously assert_malformed was treated the same as assert_invalid
Also fixes a bug where spectest-interp wasn't trying to validate
text modules (e.g. `(assert_invalid (module quote "...") "")`).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Fixes assertion failure on empty quoted module
|
| | |
|
| |
|
| |
Co-authored-by: Shravan Narayan <shravanrn@gmail.com>
|
| | |
|
| |
|
|
| |
(#2208)
|
| |
|
|
| |
used (#2226)
|
| | |
|
| | |
|
| | |
|
| |
|
| |
per http://man.openbsd.org/alloca.3
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* wasm2c: multiple .c outputs
This enables wasm2c to have multiple .c outputs, which allows parallel
compilation of the wasm2c outputs. This is useful when the input WASM module is
big.
wasm2c takes the number of .c outputs as an argument to `--num-outputs`
(defaulting to 1). If the number is equal to 1, the .c output does not change
except for two new macro declarations and the ordering of declarations and
definitions. If greater than 1, wasm2c outputs change in the following ways:
1) wasm2c outputs a [module-name]-impl.h that includes any module-wide
declarations, including:
* content of `WriteSourceTop()`
* function type declarations
* tag types
* tag declarations
* function declarations
* data segments and elem segments declarations
Any static declaration become extern in this header.
2) wasm2c outputs [module-name]_i.c for i = [0, ..., number of .c outputs - 1). Any
module-wide material is written to [module-name]_0.c, including:
* function types, tags, data segments, elem segments
* imports and exports
* module initialization, instantiation and free
3) For each function implementation, wasm2c assigns it to one output .c file
by sorting the function names and partitioning into roughly equal buckets.
Alternately, the caller can supply its own assignment function (helpful if it wants
the assignments to be more stable in the face of function insertion or deletion).
|
