WebAssembly lld port ==================== The WebAssembly version of lld takes WebAssembly binaries as inputs and produces a WebAssembly binary as its output. For the most part it tries to mimic the behaviour of traditional ELF linkers and specifically the ELF lld port. Where possible that command line flags and the semantics should be the same. Object file format ------------------ The format the input object files that lld expects is specified as part of the the WebAssembly tool conventions https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md. This is object format that the llvm will produce when run with the ``wasm32-unknown-unknown`` target. To build llvm with WebAssembly support currently requires enabling the experimental backed using ``-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly``. Usage ----- The WebAssembly version of lld is installed as **wasm-ld**. It shared many common linker flags with **ld.lld** but also includes several WebAssembly-specific options: .. option:: --no-entry Don't search for the entry point symbol (by default ``_start``). .. option:: --export-table Export the function table to the environment. .. option:: --import-table Import the function table from the environment. .. option:: --export-all Export all symbols (normally combined with --no-gc-sections) .. option:: --export-dynamic When building an executable, export any non-hidden symbols. By default only the entry point and any symbols marked with --export/--export-all are exported. .. option:: --global-base= Address at which to place global data. .. option:: --no-merge-data-segments Disable merging of data segments. .. option:: --stack-first Place stack at start of linear memory rather than after data. .. option:: --compress-relocations Relocation targets in the code section 5-bytes wide in order to potentially occomate the largest LEB128 value. This option will cause the linker to shirnk the code section to remove any padding from the final output. However because it effects code offset, this option is not comatible with outputing debug information. .. option:: --allow-undefined Allow undefined symbols in linked binary. .. option:: --import-memory Import memory from the environment. .. option:: --initial-memory= Initial size of the linear memory. Default: static data size. .. option:: --max-memory= Maximum size of the linear memory. Default: unlimited. By default the function table is neither imported nor exported, but defined for internal use only. When building shared libraries symbols are exported if they are marked as ``visibility=default``. When building executables only the entry point is exported by default. In addition any symbol included on the command line via ``--export`` is also exported. Since WebAssembly is designed with size in mind the linker defaults to ``--gc-sections`` which means that all unused functions and data segments will be stripped from the binary. The symbols which are preserved by default are: - The entry point (by default ``_start``). - Any symbol which is to be exported. - Any symbol transitively referenced by the above. Missing features ---------------- - Merging of data section similar to ``SHF_MERGE`` in the ELF world is not supported. - No support for creating shared libraries. The spec for shared libraries in WebAssembly is still in flux: https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md