compile: attempt to subtract with overflow

[MarkSwanson]

I have a small wasm function that runs fine in node.js, but causes a compile error with cretonne.

I've isolated the problem to a single wasm call() of an imported function.
In javascript I've provided the function by simply providing an object like this:
var imports = {
"env": {
"call_test": call_test }};

In Rust/cretonne I'm not sure how to provide this call_test fn.
I traced through the cretonne code and I see some nice use of dlsym(), and I will attempt at creating a DSL that contains call_test() and load it with dlopen() before using cretonne. Fingers crossed...
(Are there examples of how to do things like call(), call_indirect()?)

The following Rust code works or breaks depending on a single line:

#[no_mangle]
pub fn test(n: i32) -> i32 {
    // when compiled to wasm, call_test(1) looks like (snippets): 
    // (type (;1;) (func (param i32) (result i32)))
    // (import "env" "call_test" (func $call_test (type 1)))
    // call $call_test
    //let _a = unsafe {call_test(1)};  // <-- uncomment to show the bug
    n
}

I'd create a test and PR if someone would show me where they would like tests like this placed.

fyi the stack trace is:

thread 'main' panicked at 'attempt to subtract with overflow', /home/mswanson/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/cretonne-wasm-0.3.4/src/state.rs:212:21
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:205
3: std::panicking::default_hook
at libstd/panicking.rs:221
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:457
5: std::panicking::begin_panic_fmt
at libstd/panicking.rs:344
6: rust_begin_unwind
at libstd/panicking.rs:322
7: core::panicking::panic_fmt
at libcore/panicking.rs:71
8: core::panicking::panic
at libcore/panicking.rs:51
9: cton_wasm::state::TranslationState::peekn
at /home/mswanson/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/cretonne-wasm-0.3.4/src/state.rs:212
10: cton_wasm::code_translator::translate_operator
at /home/mswanson/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/cretonne-wasm-0.3.4/src/code_translator.rs:191
11: cton_wasm::func_translator::parse_function_body
at /home/mswanson/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/cretonne-wasm-0.3.4/src/func_translator.rs:201
12: cton_wasm::func_translator::FuncTranslator::translate_from_reader
at /home/mswanson/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/cretonne-wasm-0.3.4/src/func_translator.rs:100
13: wasmstandalone_runtime::ModuleTranslation::compile
at wasmstandalone/lib/runtime/src/lib.rs:567
...

[sunfishcode]

The demo being developed here has an example of obtaining the address of a symbols with dlsym -- it obtains the address of puts and calls it.

If you want to create a PR to add a test, if you can extract a .wat file, a good place to add it might be https://github.com/sunfishcode/wasmstandalone/tree/master/filetests. Those tests aren't yet run through a harness, so just adding the file would be enough for now.

wasmstandalone is currently a prototype, though bug reports, PRs, and test cases are useful.

[MarkSwanson]

Ok, so I see how the demo JIT uses the Cretonne SimpleJITBackend that provides finalize_function() that does the dlsym(). Cool.

I have loaded the DSO, and I have the address of the function, I just can't seem to figure out where to register the function name/address.

It seems what I need to do is figure out how wasmstandalone needs to be configured to understand imported 'env' functions - and I should probably open a ticket in the wasmstandalone project. Will do that shortly.

Thanks for all of the great wasm work! It's really fascinating stuff!
:-)

[MarkSwanson]

Closing: I have ported my code into a branch of wasmstandalone (latest cretonne) and this error has disappeared.