-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding tests for wat compatibility #33
Comments
I'd vote for wasmparser to be 100% compatible with wabt. |
wasmparser should follow the spec, which was changed to use the Note that https://webassembly.github.io/threads/ still uses the |
Thanks Benedikt and Dan for the comments! Dan, thanks for linking the updated threads spec. Following these specs (threads, bulk-memory, and core spec) there seem to be a few things that are different in the wasmparser:
I'll have a look into these issues. |
In https://webassembly.github.io/spec/core/text/instructions.html#variable-instructions the variable instructions are specified as `local.get` instead of `get_local`, and so on. This changes the disassembler (and the internal names) to match the standard. Ref: wasdk#33 Bug: https://crbug.com/1043031
In https://webassembly.github.io/spec/core/text/instructions.html#variable-instructions the variable instructions are specified as `local.get` instead of `get_local`, and so on. This changes the disassembler (and the internal names) to match the standard. Ref: wasdk#33 Bug: https://crbug.com/1043031
@ktran What's about "elem arguments"? Could you elaborate :) |
My comment on elem does not seem to be up to date anymore; it happened when parsing the |
No worries. I think all the issues here are resolved now :) |
We would like to validate that the wat output generated by the wasmparser is wat compatible for DevTools.
Would it make sense to you to include running wat2wasm's parseWat for validation? At the moment parseWat is already used in some tests in test.ts to generate the wasm binary, before disassembling it again and testing the output.
An option would be to run parseWat on the test/*out files and confirm that no error was thrown. However, in this case a few out files (4 in total, if pull request #32 is accepted) need to be excluded, as wat2wasm in some cases requires different wat format, although the format in the wasmparser is valid according to the specification (e.g. because of different naming of operators for SIMD -- i32.atomic.rmw8.add_u vs i32.atomic.rmw8_u.add, etc.). It would also be possible to adapt the output to be completely compatible with wat2wasm.
What do you think?
The text was updated successfully, but these errors were encountered: