binaryen fails to validate wasm in asm2wasm

[m4b]

I receive compile errors w.r.t. invalid wasm being generated unless I turn off the archive and mach64 features in goblin.

Dump:

asm2wasm: /home/m4b/.emscripten_ports/binaryen/binaryen-version_18/src/asm2wasm.h:1111: void wasm::Asm2WasmBuilder::processAsm(cashew::Ref): Assertion `WasmValidator().validate(wasm)' failed.
Traceback (most recent call last):
  File "/home/m4b/lib/emsdk_portable/emscripten/incoming/emcc", line 13, in <module>
    emcc.run()
  File "/home/m4b/lib/emsdk_portable/emscripten/incoming/emcc.py", line 2028, in run
    subprocess.check_call(cmd, stdout=open(wasm_text_target, 'w'))
  File "/usr/lib64/python2.7/subprocess.py", line 541, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '[u'/home/m4b/.emscripten_ports/binaryen/binaryen-version_18/bin/asm2wasm', '/home/m4b/projects/goblin/target/wasm32-unknown-emscripten/debug/examples/rdr.asm.js', '--total-memory=16777216', '--mem-init=/home/m4b/projects/goblin/target/wasm32-unknown-emscripten/debug/examples/rdr.js.mem', '--wasm-only']' returned non-zero exit status -6


error: aborting due to previous error

error: Could not compile `goblin`.

Caused by:
  process didn't exit successfully: `rustc examples/rdr.rs --crate-name rdr --crate-type bin -g --cfg feature="archive" --cfg feature="byteorder" --cfg feature="pe64" --cfg feature="goblin" --cfg feature="std" --cfg feature="elf32" --cfg feature="endian_fd" --cfg feature="default" --cfg feature="mach64" --cfg feature="pe32" --cfg feature="mach32" --cfg feature="elf64" -C metadata=17b052e017a24401 --out-dir /home/m4b/projects/goblin/target/wasm32-unknown-emscripten/debug/examples --emit=dep-info,link --target wasm32-unknown-emscripten -L dependency=/home/m4b/projects/goblin/target/wasm32-unknown-emscripten/debug/deps --extern byteorder=/home/m4b/projects/goblin/target/wasm32-unknown-emscripten/debug/deps/libbyteorder-e4fc6ea0c49cabcf.rlib --extern goblin=/home/m4b/projects/goblin/target/wasm32-unknown-emscripten/debug/deps/libgoblin.rlib` (exit code: 101)

is what I receive after it outputs an inappropriately large s-expression to stdout.

Also, it looks like file access is broken (maybe this never worked, in which case shouldn't it throw unsupported function?):

node rdr.js /bin/ls
trying binaryen method: native-wasm
no native wasm support detected
trying binaryen method: interpret-binary
binaryen method succeeded.
Not an ELF: Error { repr: Os { code: 2, message: "No such file or directory" } }

If I print the path, it is correct; it just can't find any files seemingly. Testing with simple crate with file access has similar results.

[nagisa]

Not an ELF: Error { repr: Os { code: 2, message: "No such file or directory" } }

Potentially unwinding related?

[brson]

Thanks for the report @m4b.

The invalid wasm is probably due to some LLVM construct that binaryen hasn't seen before.

The I/O error is because file access does not work in emscripten by default and requires file system emulation.

[m4b]

This seems to compile now with latest rust nightly and a newer emcc:

[ ~/projects/goblin ] rustc --version
rustc 1.16.0-nightly (47c8d9fdc 2017-01-08)
[ ~/projects/goblin ] emcc --version
emcc (Emscripten gcc/clang-like replacement) 1.37.1 (commit bf22855bf4be2080ca5a9eb8a5b667b6e17c5a36)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Unfortunately, I can't seem to get this program to run:

extern crate goblin;

use std::default::Default;

// demonstrates "automagical" elf32/64 switches via cfg on arch and pub use hacks.
// SIZEOF_* will change depending on whether it's an x86_64 system or 32-bit x86, or really any cfg you can think of.
// similarly the printers will be different, since they have different impls. #typepuns4life

#[cfg(target_pointer_width = "64")]
pub use goblin::elf64 as elf;

#[cfg(target_pointer_width = "32")]
pub use goblin::elf32 as elf;

#[cfg(any(target_pointer_width = "64", target_pointer_width = "32"))]
use elf::{header, sym};

#[cfg(any(target_pointer_width = "64", target_pointer_width = "32"))]
fn main() {
    let header: header::Header = Default::default();
    let sym: sym::Sym = Default::default();
    println!("header: {:?}, sym: {:?}", header, sym);
    println!("sizeof header: {}", header::SIZEOF_EHDR);
    println!("sizeof sym: {}", sym::SIZEOF_SYM);
}

[ ~/projects/goblin ] node target/wasm32-unknown-emscripten/debug/examples/automagic.js
trying binaryen method: native-wasm
no native wasm support detected

/home/m4b/projects/goblin/target/wasm32-unknown-emscripten/debug/examples/automagic.js:462
      throw ex;
      ^
no binaryen method succeeded. consider enabling more options, like interpreting, if you want that: https://github.com/kripken/emscripten/wiki/WebAssembly#binaryen-methods

The above uses no File or std::io so I think it should work, yes?

[m4b]

This works as expected when linked/compiled with -s "BINARYEN_METHOD='interpret-binary'" as suggested WebAssembly/binaryen#867 (comment)

[ ~/projects/goblin/target/wasm32-unknown-emscripten/debug/examples ] node automagic-1112236659a39a19.js
trying binaryen method: interpret-binary
binaryen method succeeded.
header: e_ident: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] e_type: NONE e_machine: 0x0 e_version: 0x0 e_entry: 0x0 e_phoff: 0x0 e_shoff: 0x0 e_flags: 0 e_ehsize: 0 e_phentsize: 0 e_phnum: 0 e_shentsize: 0 e_shnum: 0 e_shstrndx: 0, sym: st_name: 0 LOCAL NOTYPE st_other: 0 st_shndx: 0 st_value: 0 st_size: 0
sizeof header: 48
sizeof sym: 16

[chicoxyzzy]

@m4b alternatively you can clone this fork of Node.js, switch to vee-eight-lkgr branch, build Node and run it with --expose_wasm V8 option

[m4b]

@chicoxyzzy good to know!

I just realized I think we can force the emcc flags with something like cargo rustc --target=wasm32-unknown-emscripten -- -C link-arg="-s" -C link-arg="BINARYEN_METHOD='interpret-binary'"

[brson]

So it sounds like the original issue is fixed! Thanks @m4b and @chicoxyzzy!