<div dir="ltr">Hi Omer,<div><br></div><div>Dynamic linking support in wasm-ld is still a work in progress.    When you used the `-shared` flag to link your shared libraries you should have seen a warning like `wasm-ld: warning: creating shared libraries, with -shared, is not yet stable` (at least with ToT llvm).</div><div><br></div><div>The dynamic linking support that does exist today is mostly to support the emscripten compiler.  There is some information on the current status here: <a href="https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md#implementation-status">https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md#implementation-status</a>.</div><div><br></div><div>I am curious what your use case is.  From your description of your proposed solution it sounds like you want to be able to statically link a shared library with object files to produce what is essentially a statically linked executable.    Is that right?   In that case why not linking with the `.a` version of the library?   If you want to build a static executable you can't generally do so if you have `.so` files as input, right? (not with lld or GNU ld anyway).   I could be misunderstanding what you are asking for here...</div><div><br></div><div>The current ABI imports GOT.func and GOT.mem from the environment and relies on a dynamic linker being present in the embedder (in the case of emscripten this is implemented JavaScript).   The actual table and memory offset cannot be known statically by wasm-ld which is why those imports are generated.</div><div><br></div><div>I am keen to move the dynamic linking story forward for wasm in llvm and there plans afoot for a new stable ABI based on a new WebAssembly proposal: <a href="https://github.com/WebAssembly/module-linking/">https://github.com/WebAssembly/module-linking/</a>.   </div><div><br></div><div>cheers,</div><div>sam</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 10, 2020 at 8:05 AM Ömer Sinan Ağacan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">wasm-ld is currently unable to link a shared wasm library (generated with<br>
`wasm-ld --shared`) with .o files and produce a working executable.<br>
<br>
I'm curious if there's a fundamental reason for this, or is this simply<br>
something that wasn't needed and could be implemented if needed.<br>
<br>
I think this could be done by<br>
<br>
- Resolving "GOT.mem" and "GOT.func" imports and replacing the imports with<br>
  globals to mem/table indices of the imported symbols.<br>
<br>
- Applying dynamic relocations ($__wasm_apply_relocs) statically or dynamically<br>
  in a linker-generated start function.<br>
<br>
- (I think dylink section is not needed)<br>
<br>
For (1), for a GOT.func import, we can find the function's table index (add it<br>
to the table if it's not already added) and replace the import with the constant<br>
of the index. For GOT.mem imports it's similar, we find the location of the<br>
symbol relative to the module's memory base, then replace the import with<br>
`memory_base + offset`.<br>
<br>
For (2), in general it's not possible to run an arbitrary wasm function in link<br>
time, but I think relocation functions are basically just a list of statements<br>
(in a C-like language) `memory_base + <offset> = <address of symbol> +<br>
<constant>`. The RHS can also be `<table base> + constant`. So I think it could<br>
be run at link time.<br>
<br>
Alternatively, I think we could run $__wasm_call_ctors as first thing in a<br>
linker-generated main function after updating memory_base and table_base of the<br>
imported module and it'd apply the relocations.<br>
<br>
Would this make sense? I'm new at wasm and not too experienced in linking (just<br>
a happy user of ld.lld and gold) so it's possible that I'm missing something and<br>
this is not going to work.<br>
<br>
Thanks,<br>
<br>
Ömer<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>