Creating shared WebAssembly library

[nomeata]

I am trying to build a shared WebAssembly library (in the sense of https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md) from Rust.

The following looks promising:

#![no_main]
#![feature(link_args)]
#![allow(unused_attributes)]
#![link_args = "--import-memory"]
#![link_args = "--shared"]

// no_std just to make the output smaller and easier to understand
#![no_std]
#![feature(lang_items)]
#[lang = "eh_personality"] extern fn eh_personality() {}
use core::panic::PanicInfo;
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! { loop {} }


#[link(wasm_import_module = "import")]
extern { pub fn foo(ptr : *const u8); }


#[export_name = "start"]
pub unsafe fn start() {
    foo("Hi".as_ptr());
}

If I compile this (using --target wasm32-unknown-unknown), I get the following code:

(module
 (type $0 (func (param i32)))
 (type $1 (func))
 (type $2 (func (param i32 i32) (result i32)))
 (import "env" "memory" (memory $0 0))
 (import "env" "__indirect_function_table" (table 0 anyfunc))
 (import "env" "__stack_pointer" (global $gimport$2 i32))
 (import "env" "__memory_base" (global $gimport$3 i32))
 (import "env" "__table_base" (global $gimport$4 i32))
 (import "import" "foo" (func $foo (param i32)))
 (global $global$0 i32 (i32.const 0))
 (data (get_global $gimport$3) "\01gdb_load_rust_pretty_printers.py\00Hi")
 (export "__rustc_debug_gdb_scripts_section__" (global $global$0))
 (export "start" (func $start))
 (func $__wasm_call_ctors (; 1 ;) (type $1)
 )
 (func $_ZN4core3str21_$LT$impl$u20$str$GT$6as_ptr17hd1ab9e60453863b8E (; 2 ;) (type $2) (param $var$0 i32) (param $var$1 i32) (result i32)
  (local $var$2 i32)
  (local $var$3 i32)
  (local $var$4 i32)
  (local $var$5 i32)
  (set_local $var$2
   (get_global $gimport$2)
  )
  (set_local $var$3
   (i32.const 16)
  )
  (set_local $var$4
   (i32.sub
    (get_local $var$2)
    (get_local $var$3)
   )
  )
  (i32.store offset=8
   (get_local $var$4)
   (get_local $var$0)
  )
  (i32.store offset=12
   (get_local $var$4)
   (get_local $var$1)
  )
  (set_local $var$5
   (i32.load offset=8
    (get_local $var$4)
   )
  )
  (return
   (get_local $var$5)
  )
 )
 (func $start (; 3 ;) (type $1)
  (local $var$0 i32)
  (local $var$1 i32)
  (local $var$2 i32)
  (local $var$3 i32)
  (set_local $var$0
   (i32.const 34)
  )
  (set_local $var$1
   (get_local $var$0)
  )
  (set_local $var$2
   (i32.const 2)
  )
  (set_local $var$3
   (call $_ZN4core3str21_$LT$impl$u20$str$GT$6as_ptr17hd1ab9e60453863b8E
    (get_local $var$1)
    (get_local $var$2)
   )
  )
  (call $foo
   (get_local $var$3)
  )
  (return)
 )
 ;; custom section "dylink", size 5
 ;; custom section ".debug_info", size 1748
 ;; custom section ".debug_macinfo", size 2
 ;; custom section ".debug_pubtypes", size 959
 ;; custom section ".debug_ranges", size 32
 ;; custom section ".debug_abbrev", size 401
 ;; custom section ".debug_line", size 280
 ;; custom section ".debug_str", size 1569
 ;; custom section ".debug_pubnames", size 235
 ;; custom section "producers", size 79
)

It is very promising that this module imports __stack_pointer and __memory_base, and that it puts the static data ("\01gdb_load_rust_pretty_printers.py\00Hi") at a position that is determined by the imported __memory_base.

But when the code actually references the Hi string, in function start, it simply uses an absolute pointer, without shifting it by __memory_base:

  (set_local $var$0
   (i32.const 34)
  )

so this does not seem to be working yet.

Is there a flag I am using wrong? Or is this just not yet supported?

$ rustc --version
rustc 1.35.0-nightly (3750348da 2019-04-08)

[jonas-schievink]

Why does this need to be done? Locals should always refer to the function's stack frame implicitly.

[nomeata]

Why does this need to be done? Locals should always refer to the function's stack frame implicitly.

I am not referring to locals; the problem is the (i32.const 34): This seems to be the pointer to "Hi", as an absolute pointer. I would expect this to be (i32.add (get_global $gimport$2) (i32.const 34)), so that the address is taken relative to the __memory_base.

[nomeata]

JFTR, same happens with crate-type = ["cdylib"]

[jonas-schievink]

Ah I see, that makes more sense

[nomeata]

To reproduce without cargo, I am using this command line:

rustc  foo.rs  --crate-type cdylib -o foo.wasm  --target wasm32-unknown-unknown

[nomeata]

With -C incremental=foo I can get my hold on the .o files passed to lld, and these files are WebAssembly modules with a static linking section, including a code relocation section according to https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md, but I can see that lld isn’t really in a position to turn this into a dynamically linkable library.

Relevant bits:

$ wasm-dis foo/lib-1oxx6vmtp942d/s-fbld28zq8j-122tlgg-2xj38ws0mwqgo/x73358tcv87tyh4.o
(module
 (type $0 (func))
 (type $1 (func (param i32)))
 (type $2 (func (param i32 i32) (result i32)))
 (import "env" "__linear_memory" (memory $0 1))
 (import "env" "__indirect_function_table" (table 0 anyfunc))
 (import "env" "_ZN4core3str21_$LT$impl$u20$str$GT$6as_ptr17h490791c777cb2b36E" (func $fimport$2 (param i32 i32) (result i32)))
 (import "import" "foo" (func $fimport$3 (param i32)))
 (data (i32.const 0) "Hi")
…
 (func $2 (; 4 ;) (type $0)
…
  (set_local $var$0
   (i32.const 0)
  )
…
 )
 ;; custom section "linking", size 117
 ;; custom section "reloc.CODE", size 12
)

[nomeata]

rustc is using LLVM to generate and link WebAssembly code, right? Just to narrow down what’s happening where, here is the equivalent in C:

/tmp $ cat foo.c 
extern int bar (int, char *);

char *s = "Foo";

int foo (int n)  { return bar(n, s); }
/tmp $ clang-9 --compile -fpic foo.c  --target=wasm32-unknown-unknown-wasm --optimize=3 --output foo.o
/tmp $ wasm-ld-9 --shared --no-entry foo.o -o foo.wasm --export=foo --gc-sections
/tmp $ wasm-dis foo.wasm 
(module
 (type $0 (func (param i32 i32) (result i32)))
 (type $1 (func))
 (type $2 (func (param i32) (result i32)))
 (import "env" "memory" (memory $0 0))
 (import "env" "__indirect_function_table" (table 0 anyfunc))
 (import "env" "__memory_base" (global $gimport$2 i32))
 (import "env" "__table_base" (global $gimport$3 i32))
 (import "env" "bar" (func $bar (param i32 i32) (result i32)))
 (data (get_global $gimport$2) "Foo\00\00\00\00\00")
 (export "foo" (func $foo))
 (func $__wasm_call_ctors (; 1 ;) (type $1)
  (call $__wasm_apply_relocs)
 )
 (func $__wasm_apply_relocs (; 2 ;) (type $1)
  (i32.store
   (i32.add
    (get_global $gimport$2)
    (i32.const 4)
   )
   (i32.add
    (get_global $gimport$2)
    (i32.const 0)
   )
  )
 )
 (func $foo (; 3 ;) (type $2) (param $var$0 i32) (result i32)
  (call $bar
   (get_local $var$0)
   (i32.load
    (i32.add
     (get_global $gimport$2)
     (i32.const 4)
    )
   )
  )
 )
 ;; custom section "dylink", size 5
 ;; custom section "producers", size 52
)

Note how $foo calculates the address to the static memory based on $gimport$2.

[nomeata]

Since I passed -fpic to clang here, I tried passing -C relocation-model=pic to rustc, but the output is unchanged.

[nomeata]

Possibly related:

• Panic when used on .wasm built with -C link-arg=--shared rustwasm/wasm-bindgen#1420 (comment)
• wasm32: Default to a "static" relocation model #59712
  Maybe the conclusion is that rustc simply doesn’t support producing the PIC code needed for shared libraries.

[Arnavion]

FWIW, back in #46645 (comment) (March 2018) I had success with making a relocatable WASM module. Of course it requires a preprocessing bundler / the WASM loader to actually relocate the modules, so it's not as trivial as a PIC module.

[nomeata]

For my use case, I decided that PIC (e.g. importing a global that indicates memory offeset) is more suited than static relocation sections.