[PATCH] D40614: Add .init_array support to Wasm LLD

[Dan Gohman via Phabricator via llvm-commits]

sunfish added a comment.

> Cons:
>  Adds asymmetry to destructor handling, when it feels like they should be mirror features

Actually, it's not entirely clear that .fini_array is desirable for current wasm. It's nice to be compatible with tools that expect it, but it's usually better to use atexit/__cxa_atexit instead, because that makes it feasible to run destructors in reverse order of the runtime order of the corresponding constructors. For example, C++ uses __cxa_atexit and not .fini_array on ELF, in part for this reason.

> Won't work out of the box with musl (needless friction with upstream?)

It would be some friction. I don't think it's needless though :-).

> Less extensible to other sections. I don't expect any other sections to need this treatment, currently, but maybe other languages apart from C have initialisation concerns - like Haskell or Rust...? Sticking as close to ELF as possible for C sets a good precedent for making those other languages easy to integrate. If you're suggesting adapting Musl's startup to WebAssembly, are we going to have to adapt the runtimes of other languages too?

ELF is a standard that some tools support, so by emulating ELF, we make it easier to port these tools.

On the other hand, there are people looking to port and build tools for wasm that have no knowledge of ELF. If we do things the wasm way, rather than the ELF way, it'll be easier to promote interoperability between all these tools on wasm, because wasm is the thing they're all guaranteed to have in common.

> Assumes that start functions can be run in any order, but that's actually not exactly the case. In particular, libc does its own initialisation _before_ any user-defined constructors, so that thread-local storage and printf are usable in all user-supplied code. It's a bit cheeky of libc to get special privileges like that (by virtue of supplying the entrypoint, it's able to do its own initialisation first). There would have to be a way to force this behaviour to continue - but it wouldn't be insurmountable, you'd just to have some "loose" object file (eg. "crt2.o") that we could guarantee appears first on the link-line.

We'd just do the same thing that ELF does: order the functions in the combined start function in the order they appear on the link command line. Then we just put the initialization in crt1.o/crti.o/crtbegin.o and but those before any user code, and we're good, just like ELF.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D40614