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

[David Blaikie via llvm-dev]

(one option to allow faster progress without solving all issues in the
linker space up-front, especially when starting with an implementation in
LLD anyway, would be to make the format only compatible with lld and
potentially only compatible with a matching lld version (I don't in general
like this idea, and for example, pushed back recently on work related to
linker ODR checking that would create such a dependence for that feature -
but I think as a short/intermediate term, with the goal to working towards
a more stable/portable format it might be worth considering) - that way
there's no baked in, backwards compatible format, and you can iterate, fix
issues in the format that lead to performance issues in the linker, etc,
and then when it's baked enough, declare it to be the format that shall be
supported/portable/etc)

On Mon, Jul 3, 2017 at 11:13 AM Rafael Avila de Espindola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> 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/20170704/c120db0e/attachment-0001.html>