pepyakin / binaryen-rs Goto Github PK

Implement binaryen wasm-opt's translate-to-fuzz functionality

Rust ecosystem has a few tools that already allows you to create wasm binaries (e.g. parity-wasm, wabt). So there is not much sense to use this crate. Especially, considering the fact that binaryen-rs has not idiomatic API. That happended, because binaryen-rs uses binaryen-c.h bindings. Binaryen has a C API, but unfortunately it has some parts that are really hard to map to idiomatic Rust without actually rewriting the bindings.

Good news, it seems that there is not a lot of users of Rust bindings of Binaryen IR construction system. It seems that we can remove IR and optimize the crate for usability of other tools provided by binaryen such as translate-to-fuzz, wasm-opt and etc.

The released version 0.3.0 of this crate does not build correctly with cargo anymore, and is also missing functionality like the MVP-compatible fuzzing interface.

Current master seems to work fine though, so a published 0.3.1 or 0.4 would be nice. :)

Hey there!
I want to experiment with extending the gleam language to support compiling to webassembly. The compiler is written in rust, so I was hoping to find rust bindings to the IR construction part of binaryen. Any advice on an approach do explore would be appreciated :)

binaryen-sys crate seems to reference a fairly outdated version of binaryen by now. Any chance of updating it to latest 1.39.1? It contains a bunch of useful functions, including for enumerating functions, so that one can actually iterate over the module and perform transformations on code.

I get:

[binaryen-sys 0.6.0] fatal: Not a git repository (or any of the parent directories): .git

Which is produced by https://github.com/pepyakin/binaryen-rs/blob/master/binaryen-sys/build.rs#L141

Does cargo download these crates with their .git data?

Hiya!

I was building on ARM and ran into the issue that was fixed in #58. Would it be possible to release an 0.12.1 that would include this change? That'd be greatly appreciated 😄

Thank you!

Hi,

When I build binaryen-rs in ARM, I get the following error:

    |
 23 |         let raw_module = ffi::translateToFuzz(seed.as_ptr() as *const i8, seed.len(), false);
    |                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
    |
    = note: expected raw pointer `*const u8`
                 found raw pointer `*const i8`

This appears to be caused by translateToFuzz taking a c_char, with c_char being u8 in ARM and i8 otherwise.

Thanks,
Nicholas

Would you be willing to publish a new version of the crate that includes #62? That PR resolves an issue with a spurious warning we were seeing printed and having it published to crates.io means I wouldn't need to include this as a Git dependency.

From #22 (comment).

Binaryen has optimisation passes which have a name and a description, both are strings. The list of names (keys) can be retrieved via std::vector<std::string> PassRegistry::getRegisteredNames() and the descriptions via std::string PassRegistry::getPassDescription(std::string name).

Would be nice if we could design a dynamic API exposing this to Rust.

Two alternatives:

1. hardcode them in Rust (such as a enum as suggested by @pepyakin, where though the description could still be dynamic)
2. generate Rust code at compile time

I discovered this when executing tests for a project which uses binaryen-rs as a dependency. The project sets the optimization level to 0 during some tests.

From wasm-opt --help:

   -O0                                          execute no optimization passes 

The wasm-opt behavior:

$ wasm-opt -O0 --shrink-level=0 -o output.wasm flipper.wasm
warning: no passes specified, not doing any work

But binaryen-rs still optimizes if the optimization level and the shrink level is both set to 0:

#[test]
fn must_not_optimize_for_level_zero() {
    let input: Vec<u8> = vec![
        0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00, 0x01, 0x04, 0x01, 0x60, 0x00, 0x00,
        0x03, 0x02, 0x01, 0x00, 0x07, 0x08, 0x01, 0x04, 0x6d, 0x61, 0x69, 0x6e, 0x00, 0x00,
        0x08, 0x01, 0x00, 0x0a, 0x04, 0x01, 0x02, 0x00, 0x0b,
    ];

    let codegen_config = binaryen::CodegenConfig {
        optimization_level: 0,
        shrink_level: 0,
        debug_info: true,
    };
    let mut module = binaryen::Module::read(&input).unwrap();
    module.optimize(&codegen_config);

    // no optimization should have happened
    assert_eq!(module.write(), input);
}

This test fails for master.

I only quickly searched in the code and my hunch is that this could be a reason: