Git Product home page Git Product logo

wasmparser's Introduction

Build Status NPM version

Simple streamable WebAssembly binary parser.

Test

Compiling Code

npm run build

Examples

See the examples/ folder.

Running Tests

npm test

Creating Tests

Test .wasm files are located in the test/__fixtures__ directory. The testing harness compares the parsing output of the .wasm file against the snapshot file. You can use the npm test -- --updateSnapshot command to update the snapshot file. This is useful if you have made a change that affects the tests.

wasmparser's People

Contributors

awt-256 avatar bmeurer avatar dependabot[bot] avatar duongnhn avatar ericsl avatar jakobkummerow avatar jpages avatar ktran avatar mbebenita avatar ngzhian avatar ripdajacker avatar semantic-release-bot avatar timvdlippe avatar uplusion23 avatar yurydelendik avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wasmparser's Issues

Support loop and block parameters

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");
  1. 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.

Extract import / export type data?

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?

Can this be used for instrumentation?

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.

expose state and opcode enums

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
   .....
  } 
}

Naming of functions

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?

Disassembly is burying the lede

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,
image
followed by the imports,
image
and the exports.
image
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") ...)

The automated release is failing 🚨

🚨 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:

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 πŸ“¦πŸš€

Tests for the Emitter

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

Adding tests for wat compatibility

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?

ImportSectionEntryType does not implement clone

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.

Try using enums with named values.

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.

CI setup

@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?

Automatic releases and ChangeLog?

@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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.