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

[Dan Gohman via llvm-dev]

On Tue, Jul 4, 2017 at 2:11 PM, Rafael Avila de Espindola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Sean Silva <chisophugis at gmail.com> writes:
>
> > On Mon, Jul 3, 2017 at 11:12 AM, Rafael Avila de Espindola <
> > rafael.espindola at gmail.com> 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.
> >>
> >
> > Looking at Sam's patch, it seems like that's what it does, e.g.
> > R_WEBASSEMBLY_FUNCTION_INDEX_LEB
>
> Sorry, I meant why that didn't work with ELF (or what else didn't).
>

The standard executable WebAssembly format does not use ELF, for numerous
reasons, most visibly that ELF is designed for sparse decoding -- headers
contain offsets to arbitrary points in the file, while WebAssembly's format
is designed for streaming decoding. Also, as Sam mentioned, there are a lot
of conceptual differences. In ELF, virtual addresses are a pervasive
organizing principle; in WebAssembly, it's possible to think about various
index spaces as virtual address spaces, but not all address-space-oriented
assumptions apply.

It would also be possible for WebAssembly to use ELF ET_REL files just for
linking, however telling LLVM and other tools to target ELF tends to lead
them to assume that the final output is ELF and rely on ELF-specific
features.

The problems are solvable, but particularly for the long term, it seems
that WebAssembly would be better off using a format that fits how it
actually works, rather than using a format built around abstractions that
don't fit, even if they can be emulated.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/587b326d/attachment.html>