<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 4, 2017 at 2:11 PM, Rafael Avila de Espindola via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> writes:<br>
<br>
> On Mon, Jul 3, 2017 at 11:12 AM, Rafael Avila de Espindola <<br>
> <a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
><br>
>> Sam Clegg via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
>><br>
>> >> Can you elaborate on semantically what the linker is actually doing for<br>
>> >> wasm?<br>
>> ><br>
>> > You are correct that the wasm linker does have more work to do than a<br>
>> > traditional linker.  There are more sections that the linker will need<br>
>> > to re-construct fully.  This is because there is more high level<br>
>> > information required in the wasm format.  For example, as you point<br>
>> > out, the type of each function.   Functions also live in their own<br>
>> > index space outside of the program's memory space.  This means that<br>
>> > the simple approach of traditional linkers where almost everything can<br>
>> > be boiled down to virtual addresses don't make as much sense here.<br>
>> > This is part of the reason why early attempts to use ELF as the<br>
>> > encapsulation format were abandoned:  wasm is different enough that is<br>
>> > didn't make sense.<br>
>><br>
>> BTW, is that summarized somewhere?<br>
>><br>
>> I remember the discussion about having relocations that would resolve to<br>
>> function numbers, but I don't remember where that failed.<br>
>><br>
><br>
> Looking at Sam's patch, it seems like that's what it does, e.g.<br>
> R_WEBASSEMBLY_FUNCTION_INDEX_L<wbr>EB<br>
<br>
</span>Sorry, I meant why that didn't work with ELF (or what else didn't).<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Dan</div><div><br></div></div></div></div>