Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linking with extern function in Wasm #63562

Closed
mikevoronov opened this issue Aug 14, 2019 · 1 comment · Fixed by #67363
Closed

Linking with extern function in Wasm #63562

mikevoronov opened this issue Aug 14, 2019 · 1 comment · Fixed by #67363
Labels
A-linkage Area: linking into static, shared libraries and binaries O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@mikevoronov
Copy link

mikevoronov commented Aug 14, 2019

I am trying to use functions from an external module and importing them like that:

#[link(wasm_import_module = "sqlite")]
extern "C" {
  #[link_name="allocate"]
  pub fn allocate_external(size: usize) -> i32;
  
  #[link_name="deallocate"]
  pub fn deallocate_external(ptr: i32, size: usize);
}

But if I have exported functions with the same names in my own module, there will be linked with these local functions (in these case these functions won't be in the import section of a compiled module). Is it possible to link with functions in external module having functions with the same name in your own?

POC can be found here.

Btw, in C it could be done in this way:

#define __MODULE_IMPORT(module_name, function_name) \
    __attribute__((__import_module__(#module_name), __import_name__(#function_name)))

char *allocate_extern(int size) __MODULE_IMPORT(sqlite, allocate);
void deallocate_extern(char *ptr) __MODULE_IMPORT(sqlite, deallocate);

and works perfectly.

@mikevoronov
Copy link
Author

Hi, guys! Are there any updates?

@joelpalmer joelpalmer added A-linkage Area: linking into static, shared libraries and binaries C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Sep 16, 2019
@alexcrichton alexcrichton added the O-wasm Target: WASM (WebAssembly), http://webassembly.org/ label Dec 16, 2019
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Dec 19, 2019
…=eddyb

Fix handling of wasm import modules and names

The WebAssembly targets of rustc have weird issues around name mangling
and import the same name from different modules. This all largely stems
from the fact that we're using literal symbol names in LLVM IR to
represent what a function is called when it's imported, and we're not
using the wasm-specific `wasm-import-name` attribute. This in turn leads
to two issues:

* If, in the same codegen unit, the same FFI symbol is referenced twice
  then rustc, when translating to LLVM IR, will only reference one
  symbol from the first wasm module referenced.

* There's also a bug in LLD [1] where even if two codegen units
  reference different modules, having the same symbol names means that
  LLD coalesces the symbols and only refers to one wasm module.

Put another way, all our imported wasm symbols from the environment are
keyed off their LLVM IR symbol name, which has lots of collisions today.
This commit fixes the issue by implementing two changes:

1. All wasm symbols with `#[link(wasm_import_module = "...")]` are
   mangled by default in LLVM IR. This means they're all given unique names.

2. Symbols then use the `wasm-import-name` attribute to ensure that the
   WebAssembly file uses the correct import name.

When put together this should ensure we don't trip over the LLD bug [1]
and we also codegen IR correctly always referencing the right symbols
with the right import module/name pairs.

Closes rust-lang#50021
Closes rust-lang#56309
Closes rust-lang#63562

[1]: https://bugs.llvm.org/show_bug.cgi?id=44316
Centril added a commit to Centril/rust that referenced this issue Dec 20, 2019
…=eddyb

Fix handling of wasm import modules and names

The WebAssembly targets of rustc have weird issues around name mangling
and import the same name from different modules. This all largely stems
from the fact that we're using literal symbol names in LLVM IR to
represent what a function is called when it's imported, and we're not
using the wasm-specific `wasm-import-name` attribute. This in turn leads
to two issues:

* If, in the same codegen unit, the same FFI symbol is referenced twice
  then rustc, when translating to LLVM IR, will only reference one
  symbol from the first wasm module referenced.

* There's also a bug in LLD [1] where even if two codegen units
  reference different modules, having the same symbol names means that
  LLD coalesces the symbols and only refers to one wasm module.

Put another way, all our imported wasm symbols from the environment are
keyed off their LLVM IR symbol name, which has lots of collisions today.
This commit fixes the issue by implementing two changes:

1. All wasm symbols with `#[link(wasm_import_module = "...")]` are
   mangled by default in LLVM IR. This means they're all given unique names.

2. Symbols then use the `wasm-import-name` attribute to ensure that the
   WebAssembly file uses the correct import name.

When put together this should ensure we don't trip over the LLD bug [1]
and we also codegen IR correctly always referencing the right symbols
with the right import module/name pairs.

Closes rust-lang#50021
Closes rust-lang#56309
Closes rust-lang#63562

[1]: https://bugs.llvm.org/show_bug.cgi?id=44316
Centril added a commit to Centril/rust that referenced this issue Dec 20, 2019
…=eddyb

Fix handling of wasm import modules and names

The WebAssembly targets of rustc have weird issues around name mangling
and import the same name from different modules. This all largely stems
from the fact that we're using literal symbol names in LLVM IR to
represent what a function is called when it's imported, and we're not
using the wasm-specific `wasm-import-name` attribute. This in turn leads
to two issues:

* If, in the same codegen unit, the same FFI symbol is referenced twice
  then rustc, when translating to LLVM IR, will only reference one
  symbol from the first wasm module referenced.

* There's also a bug in LLD [1] where even if two codegen units
  reference different modules, having the same symbol names means that
  LLD coalesces the symbols and only refers to one wasm module.

Put another way, all our imported wasm symbols from the environment are
keyed off their LLVM IR symbol name, which has lots of collisions today.
This commit fixes the issue by implementing two changes:

1. All wasm symbols with `#[link(wasm_import_module = "...")]` are
   mangled by default in LLVM IR. This means they're all given unique names.

2. Symbols then use the `wasm-import-name` attribute to ensure that the
   WebAssembly file uses the correct import name.

When put together this should ensure we don't trip over the LLD bug [1]
and we also codegen IR correctly always referencing the right symbols
with the right import module/name pairs.

Closes rust-lang#50021
Closes rust-lang#56309
Closes rust-lang#63562

[1]: https://bugs.llvm.org/show_bug.cgi?id=44316
@bors bors closed this as completed in aa0ef5a Dec 20, 2019
mikevoronov added a commit to fluencelabs/marine-rs-sdk that referenced this issue Apr 28, 2020
mikevoronov added a commit to fluencelabs/sqlite that referenced this issue Apr 28, 2020
mikevoronov added a commit to fluencelabs/redis that referenced this issue Jun 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants