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

Dan Gohman via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 6 12:09:44 PDT 2017

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.
> 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

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.

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

More information about the llvm-dev mailing list