Question

我最近开始学习wasm-bindgen。即使是第一个例子，js-hello-world也存在一个奇怪的问题。 https://github.com/rust-lang-nursery/rust-wasm

我按照写的做了，每晚都设定rustc，然后：

rustup target add wasm32-unknown-unknown
cargo install wasm-bindgen-cli
cargo new js-hello-world --lib

这是Cargo.toml：

[package]
name = "js-hello-world"
version = "0.1.0"
authors = ["myname@mydomain.com"]

[dependencies]
wasm-bindgen = "0.2.1"

[lib]
crate-type = ["cdylib"]

和lib.rs：

#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
extern crate wasm_bindgen;

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}

现在我建立时：

cargo build --target=wasm32-unknown-unknown -vv

编译实际挂起甚至不消耗cpu资源：

   Fresh unicode-xid v0.1.0
   Fresh serde v1.0.37
   Fresh fnv v1.0.6
   Fresh num-traits v0.2.2
   Fresh dtoa v0.4.2
   Fresh itoa v0.4.1
   Fresh proc-macro2 v0.3.6
   Fresh serde_json v1.0.13
   Fresh quote v0.5.1
   Fresh syn v0.13.1
   Fresh serde_derive_internals v0.23.0
   Fresh serde_derive v1.0.37
   Fresh wasm-bindgen-shared v0.2.1
   Fresh wasm-bindgen-backend v0.2.1
   Fresh wasm-bindgen-macro v0.2.1
   Fresh wasm-bindgen v0.2.1
   Compiling js-hello-world v0.1.0 (file:///home/markelovg/container/js-hello-world)
 Running `rustc --crate-name js_hello_world src/lib.rs --crate-type cdylib --emit=dep-info,link -C debuginfo=2 -C metadata=a4ec1c36c55eb3a5 --out-dir /home/markelovg/container/js-hello-world/target/wasm32-unknown-unknown/debug/deps --target wasm32-unknown-unknown -C incremental=/home/markelovg/container/js-hello-world/target/wasm32-unknown-unknown/debug/incremental -L dependency=/home/markelovg/container/js-hello-world/target/wasm32-unknown-unknown/debug/deps -L dependency=/home/markelovg/container/js-hello-world/target/debug/deps --extern wasm_bindgen=/home/markelovg/container/js-hello-world/target/wasm32-unknown-unknown/debug/deps/libwasm_bindgen-a2e136f9a24e6618.rlib`

我的项目中存在此libwasm_bingden-a2e136f9a24e6618.rlib依赖项，但之后什么也没发生。如何解决这个问题？

我还尝试将gdb用于lld进程，这是输出：

    (gdb) bt
    #0 0xb7753cf9 in __kernel_vsyscall ()
    #1 0xb7727800 in futex_wait_cancelable (private=, expected=0, futex_word=0xbf817dac) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
    #2 __pthread_cond_wait_common (abstime=0x0, mutex=0xbf817d6c, cond=0xbf817d84) at pthread_cond_wait.c:502
    #3 __pthread_cond_wait (cond=0xbf817d84, mutex=0xbf817d6c) at pthread_cond_wait.c:655
    #4 0x09dec825 in __gthread_cond_wait (__mutex=, __cond=0xbf817d84)
    at /tmp/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/gthr-default.h:864
    #5 std::condition_variable::wait (this=0xbf817d84, __lock=...) at ../../../../../../gcc-4.8.5/libstdc++-v3/src/c++11/condition_variable.cc:52
    #6 0x08308ce9 in lld::wasm::writeResult() ()
    #7 0x082f8580 in (anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) [clone .constprop.291] ()
    #8 0x082f8cbc in lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) ()
    #9 0x08093078 in main ()

有人可以向我澄清为什么它会在__kernel_vsyscall（）中等待吗？

Answer 1

当系统调用被阻止时，进程会在__kernel_vsyscall()中等待。

我无法说出为什么在这种特殊情况下：我已经使用您的食谱在我的机器上进行了快速测试，但它确实有效。

查看日志似乎你有一个64位目标（x86_64-unknown-linux-gnu），但从评论看来你似乎使用i686 cpu的工具链。

验证工具链是否为nightly-x86_64-unknown-linux-gnu。

Answer 2

最近尝试在x86-64 linux-gnu操作系统上构建这个例子并且它已经通过了。所以这个问题与来自wasm-bindgen本身的32位平台的弱支持有关。谢谢

libwasm_bindgen-a2e136f9a24e6618.rlib挂起并且在编译时不消耗CPU

2 个答案: