wasm cannot import globals

[fengb]

Wasm allows you to import global variables:

(module
  (type (;0;) (func (param i32)))
  (type (;1;) (func))
  (import "env" "frobinate" (func $frobinate (type 0)))
  (import "env" "glob" (global (;0;) i32))
  (func (;1;) (type 1)
    global.get 0
    call $frobinate))

But I can't seem to do this in Zig because lld attempts to resolve the variable symbols at link time:

extern "env" fn frobinate(num: u32) void; // this works just fine
extern "env" const glob: u32; // this doesn't work

export fn foo() void {
    frobinate(glob);
}

// $ zig build-lib extern.zig -dynamic -target wasm32-freestanding
// lld: error: ./extern.o: undefined symbol: glob

[kubkon]

This one is really interesting! Do you have any particular example in mind? The example you pasted in in the issue description is actually not corresponding to the Zig's source since foo is not actually exported in your WAT source. I'm sure it's just a typo, but for completeness sake, I guess something like this is what we'd like to support (please verify me here @fengb):

; globals.wat
(module
  (type (;0;) (func (param i32)))
  (type (;1;) (func))
  (import "env" "frobinate" (func $frobinate (type 0)))
  (import "env" "glob" (global (;0;) i32))
  (export "foo" (func $foo))
  (func $foo (type 1)
    global.get 0
    call $frobinate
    return))

Then, we could link that with the following module at runtime:

; globals_env.wat
(module
  (type (;0;) (func (param i32)))
  (global i32 (i32.const 10)) (export "glob" (global 0))
  (export "frobinate" (func $frobinate))
  (func $frobinate (type 0) (param i32)
    return))

You can actually verify that it (at least) doesn't trap using Wasmtime like so:

wasmtime globals.wat --preload env=globals_env.wat --invoke foo

Now, to the issue at hand, I think this might be a problem with lld itself, as I'm having really hard time at getting this to not throw the exact same error in Rust and C. I'll ask around in the Wasm community what their thoughts are on this and report back.

[kubkon]

Update: I’ve confirmed that it’s the limitation of LLVM. I’m not sure what the best course of action here is. We could submit an upstream proposal/request for this I guess and work with the LLVM devs at getting it implemented. Thoughts?

[fengb]

With the latest compiler, this is no longer a compile error but instead a miscompilation:

(module
  (type (;0;) (func (param i32)))
  (type (;1;) (func))
  (import "env" "frobinate" (func $frobinate|env (type 0)))
  (func $__wasm_call_ctors (type 1))
  (func $foo (type 1)
    i32.const 0
    i32.load
    call $frobinate|env)
  (memory (;0;) 2)

Instead of an import, this function uses the (non-exposed) 0 address in the internal memory.

[Luukdegram]

This is actually working as intended.
This is why:
Top-level declarations actually live in the data section (Similar to .bss section for ELF). This is also why you're seeing instructions for loading from memory. What this means is that glob is actually being compiled to an undefined 'data' symbol in the object file. As we link statically, the linker is trying to resolve the undefined symbol during link time, which it can't resolve (hence the error that was being output previously. But since we append --allow-undefined by default, you no longer get that error). When wasm-ld performs relocations for this symbol, it writes 0 as it is undefined.

This does mean above use case is not supported (in no other language such as Rust, C, etc really). While above behavior is correct, it means the user must be aware of the semantics of how declarations live in the linear memory rather than wasm's globals which is very unfortunate.

One possible solution would be to support something like extern "wasm" const foo: i32;, but that would only be supported by the wasm backend as there's no way to tell llvm to use a wasm global instead. Linking with other languages would yield an error but that is fine as such 'wasm' ABI isn't stable anyway so users would have to revert to status quo for that.

[zigazeljko]

there's no way to tell llvm to use a wasm global instead

There is, actually. Since this patch got merged, you can create wasm globals by using addrspace(1) in LLVM IR.

[Luukdegram]

there's no way to tell llvm to use a wasm global instead

There is, actually. Since this patch got merged, you can create wasm globals by using addrspace(1) in LLVM IR.

Thanks for that! Not sure how I missed that but glad I was proven wrong. Considering stage2 supports address spaces we could support this in both backends then.

[ElectroluxV2]

Hi, do you have any workaround to this issue? Or should I ignore it and just use bunch of extern constant functions?