llvm dev - Jul 2017 - [LLD] Adding WebAssembly support to lld

Can you link to docs about the wasm object format? (both relocatable and
executable)

Also, traditional object file linkers are primarily concerned with
concatenating binary blobs with small amount of patching of said binary
blobs based on computed virtual (memory) addresses. Or perhaps to put it
another way, what traditional object file linkers do is construct program
images meant to be mapped directly into memory.

My understanding is that wasm is pretty different from this (though "linker
frontend" things like the symbol resolution process is presumably similar).
Looking at Writer::run in your patch it seems like wasm is indeed very
different. E.g. the linker is aware of things like "types" and knowing
internal structure of functions (e.g. write_sig knows about how many
parameters a function has)

Can you elaborate on semantically what the linker is actually doing for
wasm?

-- Sean Silva

On Fri, Jun 30, 2017 at 4:46 PM, Sam Clegg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi llvmers,
>
> As you may know, work has been progressing on the experimental
> WebAssembly backend in llvm.  However,  there is currently not a good
> linking story.  Most the of existing linking strategies (i.e. those in
> the emscripten toolchain) involve bitcode linking and whole program
> compilation at link time.
>
> To improve this situation I've been working on adding a wasm backend
> for lld.   My current work is here: https://reviews.llvm.org/D34851
>
> Although this port is not ready for production use (its missing
> several key features such as comdat support and full support for weak
> aliases) its already getting a some testing on the wasm waterfall:
> https://wasm-stat.us/builders/linux
>
> I'm hopeful that my patch may now be at an MVP stage that could be
> considered for merging into upstream lld.  Thoughts?  LLD maintainers,
> would you support the addition of a new backend?
>
> cheers,
> sam
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20170630/331b03a0/attachment.html>

Sam Clegg via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> Can you elaborate on semantically what the linker is actually doing for
>> wasm?
>
> You are correct that the wasm linker does have more work to do than a
> traditional linker.  There are more sections that the linker will need
> to re-construct fully.  This is because there is more high level
> information required in the wasm format.  For example, as you point
> out, the type of each function.   Functions also live in their own
> index space outside of the program's memory space.  This means that
> the simple approach of traditional linkers where almost everything can
> be boiled down to virtual addresses don't make as much sense here.
> This is part of the reason why early attempts to use ELF as the
> encapsulation format were abandoned:  wasm is different enough that is
> didn't make sense.
BTW, is that summarized somewhere?

I remember the discussion about having relocations that would resolve to
function numbers, but I don't remember where that failed.

Cheers,
Rafael