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

[Ömer Sinan Ağacan via llvm-dev]

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