Output incompatible with wabt (wasm2wast & wast2wasm)

[Fishrock123]

The wabt tools wasm2wast & wast2wasm seem to run a different version of webassembly, or something.

I find this particularly odd given that I've been able to run the same mir2wasm code on Chrome Stable 56.0.2924.87 (64-bit) with chrome://flags/#enable-webassembly. I'm running wabt master.

The example errors both use this math.rs file:

#![feature(intrinsics, lang_items, start, no_core, fundamental)]
#![no_core]

#[lang = "sized"]
#[fundamental]
pub trait Sized { }

#[lang = "copy"]
pub trait Copy : Clone { }

pub trait Clone : Sized { }

#[lang = "mul"]
pub trait Mul<RHS = Self> {
    type Output;
    fn mul(self, rhs: RHS) -> Self::Output;
}

impl Mul for i32 {
    type Output = i32;
    fn mul(self, rhs: i32) -> Self::Output { self * rhs }
}

fn main() {}

pub fn doubler(val: i32) -> i32 {
    val * 2
}

wasm2wast

Where ./math.wasm was made via mir2wasm with cargo run -q -- ../wasm/math.rs -o ../wasm/math.wasm

wasm2wast ./math.wasm -o ./math.wast
error: @0x00000008: bad wasm file version: 0xd (expected 0x1)

wast2wasm

Where ./math.wast was made via copying the stdout output of cargo run -q -- ../wasm/math.rs into a file.

~/D/h/wasm> wast2wasm ./math.wast
./math.wast:123:12: type stack size too small at implicit return. got 0, expected at least 1
          (return
           ^^^^^^
./math.wast:217:12: type stack size too small at implicit return. got 0, expected at least 1
          (return
           ^^^^^^

[eholk]

Can you try building with the branch in this PR? https://github.com/brson/mir2wasm/pull/61

I think these issues should be fixed there.

[Fishrock123]

Odd, when I try to manually change the bit, wasm2wast works but chrome gives me:

Uncaught (in promise) CompileError: WebAssembly.compile(): Wasm decoding failedResult = expected version 0d 00 00 00, found 01 00 00 00 @+4

[Fishrock123]

Hmmm, Firefox Nightly and Chrome Canary appear to fail before and after the bit modification.

I'll try the new branch shortly.

[Fishrock123]

@eholk #61 currently fails for me with:

env RUST_BACKTRACE=1 cargo run -q -- ../here-be-dragons/wasm/math.rs -o ../here-be-dragons/wasm/math.wasm
[wasm-validator error in function $doubler] 1 != 0: function body type must match, if function returns, on
[none] [none] (block
  [unreachable] (block $block$1$break
    [none] (set_local $5
      [i32] (i32.load
        [i32] (i32.const 0)
      )
    )

;; etc ...

            [unreachable] (return
              [i32] (get_local $4)
            )
          )
        )
      )
    )
  )
)
[wasm-validator error in function $_i32_as_Mul_::mul] 1 != 0: function body type must match, if function returns, on
[none] [none] (block
  [unreachable] (block $block$1$break
    [none] (set_local $8
      [i32] (i32.load
        [i32] (i32.const 0)
      )
    )
    [unreachable] [unreachable] (block
      [unreachable] (br $block$1$break)
    )

;; etc ...

            )
            (return
              (get_local $7)
            )
          )
        )
      )
    )
  )
)
thread 'main' panicked at 'Internal compiler error: invalid generated module', src/trans.rs:86
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: mir2wasm::trans::trans_crate
   1: <mir2wasm::WasmCompilerCalls as rustc_driver::CompilerCalls<'a>>::build_controller::{{closure}}
   2: rustc_driver::driver::compile_input::{{closure}}
   3: rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}
   4: rustc_driver::driver::phase_3_run_analysis_passes
   5: rustc_driver::driver::compile_input
   6: rustc_driver::run_compiler
   7: mir2wasm::main

[Fishrock123]

Oops, just realized that wasn't the "full" backtrace!

thread 'main' panicked at 'Internal compiler error: invalid generated module', src/trans.rs:86
stack backtrace:
   0:        0x106e88273 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::h725ad67c9efc8e48
   1:        0x106e94ba4 - std::panicking::default_hook::{{closure}}::he22ccdb3d6013058
   2:        0x106e947cd - std::panicking::default_hook::h61d415f2381a7336
   3:        0x106e972e7 - std::panicking::rust_panic_with_hook::h8e6300d8e8aca457
   4:        0x101d56aa3 - std::panicking::begin_panic::h3bb0bafb0aa2873e
   5:        0x101dd1e8b - mir2wasm::trans::trans_crate::h1dcc0d1d4954238a
   6:        0x101d30a43 - <mir2wasm::WasmCompilerCalls as rustc_driver::CompilerCalls<'a>>::build_controller::{{closure}}::hf8886260b132d252
   7:        0x10287c71b - rustc_driver::driver::compile_input::{{closure}}::hb36ce61470c17f50
   8:        0x1028ad34d - rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}::hde20c2ffd55e25e7
   9:        0x10288f1c2 - rustc_driver::driver::phase_3_run_analysis_passes::hb97900a0165c0fef
  10:        0x10287aaac - rustc_driver::driver::compile_input::hd50a6918443232a0
  11:        0x1028c000e - rustc_driver::run_compiler::h5151bfc01962b066
  12:        0x101d31b69 - mir2wasm::main::h9d2a264944a9b367
  13:        0x106e9a06a - __rust_maybe_catch_panic
  14:        0x106e97c06 - std::rt::lang_start::he28fbf70e98a2b18
  15:        0x101d323a9 - main

[eholk]

I just gave your test program a try on my latest branch and it seems to have worked fine for me! I tested on https://github.com/eholk/mir2wasm/tree/refactor, but this shouldn't be materially different from https://github.com/eholk/mir2wasm/tree/test-fix (#61).

[Fishrock123]

@eholk I get an identical error and backtrace on the refactor branch.

I'm running: macOS 10.10.5, rustc 1.17.0-nightly (c0b7112ba 2017-03-02). I can get more info if I know how haha. :)

Update: the error is pretty much the same on latest nightly.

[eholk]

Is your binaryen submodule up to date? The validation errors like you're seeing were due to a bug in binaryen (fix in https://github.com/WebAssembly/binaryen/pull/940). I recently switched the submodule to my own fork of binaryen, which has caused me a little trouble when I update on my various machines.

As far as getting more info, the most useful output is actually the binaryen validation errors that are at the top.

It's good to hear this still builds on the latest nightly! Most of my time on this project seems to be spent keeping up with the churn in rustc :).

[Fishrock123]

Hmmm, getting this:

git submodule update
fatal: reference is not a tree: c565ebf4d16ef7840cfb6cde335172c7d63d736f
Unable to checkout 'c565ebf4d16ef7840cfb6cde335172c7d63d736f' in submodule path 'binaryen'

Perhaps I'm not updating it correctly?

[eholk]

Ah, this is the problem I've been running into on my different machines. Here's how to fix it:

cd binaryen
git remote add eholk https://github.com/eholk/binaryen.git
git fetch eholk
cd ..
git submodule update

[Fishrock123]

Hmmm, got that to run but still getting this error from wasm2wast: error: @0x00000008: bad wasm file version: 0xd (expected 0x1).

[eholk]

Is that using the wasm2wast from wasm-install/bin?

Does cargo test succeed?

[Fishrock123]

cargo test passes.

I'm using the tools compiled from wabt directly, at 81a64d68c7ce50617bac025061d8f6db91b00ee9 from wabt master.

[eholk]

Hmm, this is perplexing. As far as I can tell, everything should be emitting and expecting 0x1 instead of 0xd.

Is there any chance your .wasm file is stale, like perhaps you've forgotten to give the -o math.wasm option in awhile?

[Fishrock123]

Nope, just regenerated it and it's the same thing. Here's the first bunch of the file in hex:

00 61 73 6d 0d 00 00 00 01 92 80 80 80 00 04 60 00 00 60 00 00 60 01 7f 01 7f 60 02 7f 7f 01 7f 03 85 80 80 80 00 04 00 01 02 03 05 84 80 80 80 00 01 ...

[Fishrock123]

OK. Looks like I didn't both checkout the branch of mir2wasm and binaryen properly.

Here's the hex now:

00 61 73 6d 01 00 00 00 01 92 80 80 80 00 04 60 00 00 60 00 00 60 01 7f 01 7f 60 02 7f 7f 01 7f 03 85 80 80 80 00 04 00 01 02 03 05 84 80 80 80 00 01 ...

Seems to be working with those fixes!

[eholk]

Great, I'm glad to hear it's working!

I'll close the issue now, but feel free to reopen it if there's anything still unresolved.