[llvm-dev] (wasm-ld) Any fundamental problems with linking a shared wasm library statically?

[Sam Clegg via llvm-dev]

Hi Omer,

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).

The dynamic linking support that does exist today is mostly to support the
emscripten compiler.  There is some information on the current status here:
https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md#implementation-status
.

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...

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.

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:
https://github.com/WebAssembly/module-linking/.

cheers,
sam

On Mon, Aug 10, 2020 at 8:05 AM Ömer Sinan Ağacan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> wasm-ld is currently unable to link a shared wasm library (generated with
> `wasm-ld --shared`) with .o files and produce a working executable.
>
> I'm curious if there's a fundamental reason for this, or is this simply
> something that wasn't needed and could be implemented if needed.
>
> I think this could be done by
>
> - Resolving "GOT.mem" and "GOT.func" imports and replacing the imports with
>   globals to mem/table indices of the imported symbols.
>
> - Applying dynamic relocations ($__wasm_apply_relocs) statically or
> dynamically
>   in a linker-generated start function.
>
> - (I think dylink section is not needed)
>
> For (1), for a GOT.func import, we can find the function's table index
> (add it
> to the table if it's not already added) and replace the import with the
> constant
> of the index. For GOT.mem imports it's similar, we find the location of the
> symbol relative to the module's memory base, then replace the import with
> `memory_base + offset`.
>
> For (2), in general it's not possible to run an arbitrary wasm function in
> link
> time, but I think relocation functions are basically just a list of
> statements
> (in a C-like language) `memory_base + <offset> = <address of symbol> +
> <constant>`. The RHS can also be `<table base> + constant`. So I think it
> could
> be run at link time.
>
> Alternatively, I think we could run $__wasm_call_ctors as first thing in a
> linker-generated main function after updating memory_base and table_base
> of the
> imported module and it'd apply the relocations.
>
> Would this make sense? I'm new at wasm and not too experienced in linking
> (just
> a happy user of ld.lld and gold) so it's possible that I'm missing
> something and
> this is not going to work.
>
> Thanks,
>
> Ömer
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200810/687a0110/attachment.html>