Rafael Avila de Espindola via llvm-dev
2017-Jul-03 18:12 UTC
[llvm-dev] [LLD] Adding WebAssembly support to lld
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
David Blaikie via llvm-dev
2017-Jul-04 15:22 UTC
[llvm-dev] [LLD] Adding WebAssembly support to lld
(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>
Sean Silva via llvm-dev
2017-Jul-04 20:10 UTC
[llvm-dev] [LLD] Adding WebAssembly support to lld
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 -- Sean Silva> > Cheers, > Rafael >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170704/a0ab4c6f/attachment-0001.html>
Rafael Avila de Espindola via llvm-dev
2017-Jul-04 21:11 UTC
[llvm-dev] [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_LEBSorry, I meant why that didn't work with ELF (or what else didn't). Cheers, Rafael