rustwasm / wasm-snip Goto Github PK

Motivation

std::panicking::panicking() is a simple function that checks to see if the current thread is panicking. Looking at the wasm-snip source code, it appears that this will be targeted by this pattern when --snip-rust-panicking-code is used:

options.patterns.push(r#".*std\.\.panicking\.\..*"#.into());

It is unfortunate because this function is called by std::thread::panicking(); a function extensively used by tokio

Proposed Solution

Omit this particular function from the patterns, or somehow snip this particular function to always return false

Do you have any plans for adding a similar feature to https://github.com/WebAssembly/binaryen? I'm curious because it feels that this could have been implemented as a Binaryen pass. Have you looked into that as a possibility? Last I checked, Binaryen didn't have a way to pass arguments to passes (@kripken is that still true), but if that's making it difficult for developers to extend Binaryen we should add that feature.

I get very weird and long error when trying to use wasm-snip on my project.
https://github.com/jaroslaw-weber/cbt-diary/tree/master/cbt_diary_wasm
If I replace current build script ( build.sh ) to this:

echo "building wasm file"
cargo web build
cp target/wasm32-unknown-unknown/release/cbt_diary_wasm.js generated/cbt_diary_wasm.js
cp target/wasm32-unknown-unknown/release/cbt_diary_wasm.wasm generated/cbt_diary_wasm.wasm
wasm-gc generated/cbt_diary_wasm.wasm
wasm-snip generated/cbt_diary_wasm.wasm
wasm-gc generated/cbt_diary_wasm.wasm
wasm-opt generated/cbt_diary_wasm.wasm

I get very nasty error.

Describe the Bug

wasm-snip fails to parse Wasm that contains SIMD instructions such as v128:

error: failed to parse code section
  caused by found type v128
  caused by expected type i32
  caused by The input WebAssembly is invalid

Steps to Reproduce

1. Take a Wasm file that uses SIMD instructions (example: https://ameo.link/u/8oc.wasm)
2. Use it as input for wasm-snip: wasm-snip 8oc.wasm

Additional Context

This might just be a matter of bumping the wasm parsing libraries. However, some other Wasm tooling I use wasm-opt and wasm2wat both require special command line arguments to be passed in order to deal with SIMD.

$ rustup update nightly
… latest update on 2018-08-14, rust version 1.30.0-nightly (d5a448b3f 2018-08-13) …

$ cargo test
fail because the “name” section is not in the WASM binary

This can be viewed with:

$ cd tests
$ rustc +nightly --target wasm32-unknown-unknown -O -g ./hello.rs
$ twiggy top hello.wasm | head -n 15
 Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼──────────────────────
          3460 ┊     6.68% ┊ code[119]
          3169 ┊     6.12% ┊ data[0]
          1581 ┊     3.05% ┊ code[170]
          1304 ┊     2.52% ┊ code[177]
          1210 ┊     2.34% ┊ code[154]
          1113 ┊     2.15% ┊ code[165]
           942 ┊     1.82% ┊ code[168]
           926 ┊     1.79% ┊ code[124]
           747 ┊     1.44% ┊ code[122]
           710 ┊     1.37% ┊ code[148]
           696 ┊     1.34% ┊ code[184]
           695 ┊     1.34% ┊ code[19]
           694 ┊     1.34% ┊ code[149]

The debug symbols are missing.

If we remove the -O option, it's working. I suspect this is a regression in rustc.

This seems to be more useful in many cases. I just want to know whether this is technically possible.

When trying to execute wasm-snip on my project, I'm getting this error:

 wasm-snip target/wasm32-unknown-unknown/release/wasmboy_zip.wasm
 asm╔   ╔error: I/O Error: text was not valid unicode

This seems to happen with any configuration / flag combination I try to use it with.