See WebAssembly/spec#1228 (comment): prefix is a single byte, and what follows is a LEB128

The changes in the https://github.com/WebAssembly/spec/pull/1235/files#diff-59c366fbc32de0cb02b330bf7871317f shows that we cannot just read a byte -- operator can be represented as extended LEB

see WebAssembly/simd#209

Currently we can have different names for functions, either $func<id>, $imported<id> or $unknown<id>. Specifically for the first two, is there a particular reason for the distinction? How about just always using $func<id>? Would that be okay as well?

Some of those test files (.wasm) are out of date, using older opcodes. Were they generated from somewhere?

In other words, having both a streaming reader and a writer. I'm looking to instrument all memory reads / writes and this looks like the perfect place to start.

Can we use enums with names values, so instead of:

pub enum ParserState<'a> {
  BeginWasm(u32, u32),
}

something like

pub enum ParserState<'a> {
  BeginWasm {magic_number: u32, version: u32},
}

I feel like this would help with documentation. I tried switching the code to do this and I ran into a bunch of errors. I don't know Rust very well so I don't know if there are any drawbacks to this.

Upstream issue of chromium:1092763.

The current WAT compatible disassembly adds quite a lot of overhead in the beginning that the developer has to scroll across before getting to the meaty parts of the disassembly. the attached screenshots show the disassembly from chromium:1058836 to illustrate the problem:

It starts with all the types,

followed by the imports,

and the exports.

In between the latter two, the globals are hidden.

We propose to simplify this as follows:

1. Don't print the types individually, but rather have them implicit in the (func ...) declarations. This is still valid WAT and still gives the developer all the necessary information.
2. Print the imports in the form (func $foo (import "bar" "foo") ...) so that it looks uniform with the function declarations from the module itself.
3. Inline the exports into the function declarations, like this (func $baz (export "g") (export "f") ...)

See multiplier number isn't correct from firefox disassemble code - https://bugzilla.mozilla.org/show_bug.cgi?id=1504654

https://github.com/wasdk/wasmparser/blob/master/src/WasmDis.ts#L652

Maybe just expand the existing test suite to parser -> emitter -> check if equal.

I am looking for a way to programmatically extract the complete list of imports and exports from a WASM module along with each im/export's full type signature. It looks like this library might be just what I need, but the documentation doesn't really make it obvious how that could be accomplished. Is there an easy way to do it, or do I need to keep looking elsewhere?

@yurydelendik how do you feel about setting up Travis CI (there's already .travis.yml?) or GitHub Actions to run the tests on pull requests and commits?

@yurydelendik looks like Travis doesn't run npm test anymore again, for example see https://travis-ci.org/github/wasdk/wasmparser/builds/696495499 from my latest PR.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

ImportSectionEntryType in parser.rs does not derive clone, but it probably should. Changing it to carry reference types would be a breaking change anyway, so no reason for it not to be cloneable. (This makes to ergonomics of the library slightly better.)

The same argument might be made for the other simple enums in the module.

Currently: i32x4.dot_i8x16_i7x16_add_s. See also i16x8.dot_i8x16_i7x16_s

Steps to reproduce:

1. Open https://wingolog.org/pub/ in firefox nightly
2. Open a debugger for the newly opened tab
3. Open a console and type:

async function loadWasm(url, imports) {
  let {module, instance} = await WebAssembly.instantiateStreaming(fetch(url), imports);
  return instance.exports.run;
}
var sum = await loadWasm("https://wingolog.org/pub/sum.wasm");

4. Go to the "sum.wasm" page in the sources tab

Expected behavior: I see wasm disassembly

Actual behavior: blank page; error on the command-line:

console.error: (new Error("Unexpected type 1", "resource://devtools/client/shared/vendor/WasmDis.js", 40))
console.warn: "Action loadSourceText had an exception:" (new Error("Unexpected type 1", "resource://devtools/client/shared/vendor/WasmDis.js", 40))

See https://bugzilla.mozilla.org/show_bug.cgi?id=1628352.

@yurydelendik you mention that it is "streamable" parser. Could you provide and example of usage with the streams?

If this is intended to be used as a library then it would be nice if the this was publically exposed to JS.

Currently I want to implement a consumer I need to recreate it.

 const ReaderState = {
  ERROR: -1,
  INITIAL: 0,
  BEGIN_WASM: 1,
  END_WASM: 2,
  BEGIN_SECTION: 3,
  END_SECTION: 4,
  TYPE_SECTION_ENTRY: 11,
  IMPORT_SECTION_ENTRY: 12,
  FUNCTION_SECTION_ENTRY: 13,
  TABLE_SECTION_ENTRY: 14,
  MEMORY_SECTION_ENTRY: 15,
  GLOBAL_SECTION_ENTRY: 16,
  EXPORT_SECTION_ENTRY: 17,
  NAME_SECTION_ENTRY: 19,
  BEGIN_FUNCTION_BODY: 20,
  END_FUNCTION_BODY: 30,
  READING_FUNCTION_HEADER: 31,
  SKIPPING_FUNCTION_BODY: 32,
  CODE_OPERATOR: 33,
  SKIPPING_SECTION: 35,
  BEGIN_INIT_EXPRESSION_BODY: 40,
  END_INIT_EXPRESSION_BODY: 41,
  INIT_EXPRESSION_OPERATOR: 42
}

const dis = new wasmdis.WasmDisassembler()
const data = new Uint8Array(fs.readFileSync(file))
const parser = new wasmparser.BinaryReader(data)
parser.setData(data.buffer, 0, data.length)

while (parser.read()) {
  switch (parser.state) {
    case ReaderState.BEGIN_WASM: 
      console.log('BEGIN WASM')
    break
   .....
  } 
}

@yurydelendik, I stumbled across this repository looking for https://github.com/bytecodealliance/wasmparser. Is this an old version of that and, if so, should we archive it?

sorry, wrong repo :(

@yurydelendik do you mind if I add prettier for automatic formatting of the sources?

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?

is not displayed correctly

Now ref.cast $type

@yurydelendik have you considered automating releases (via for example semantic-release)? And especially also generating a ChangeLog based on the git commits (whose style is enforced via git hooks)? It's not strictly necessary, but it'd make change tracking easier for us, since downstream we'd just get the ChangeLog diff and could see exactly what happened in each commit?

Also it'd probably reduce the amount of manual work on your side considerably.

This is not tested functionality (see #11) and it was not fully developed. Let's remove this functionality.

Tracking WebAssembly/simd#452