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

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

Cheers,
Rafael

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>

Dan Gohman <sunfish at mozilla.com> writes:
>> 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.
I can see why you would want your own format for distribution. My
question was really about using ELF for the .o files.
> 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.
Things like "the dynamic linker implements copy relocations"?

Cheers,
Rafael