[lld] [WebAssembly] Generate a call to __wasm_apply_global_tls_relocs in __wasm_init_memory (PR #149832)

[via llvm-commits]

Arshia001 wrote:

> depends on `__wasm_apply_tls_relocs` being exported

I believe we also did a patch that made `__wasm_apply_tls_relocs` public so it can be exported.

I just went over your code. The issue is with a bad implementation in the linker; the steps I outlined above are sound (when implemented correctly) AFAICT. I know the flow is rather complex, but it enables the linker implementation to do things exactly as it needs to.

For example, in our implementation, we go the emscripten way of exporting all libc functions from the main module, so we want the main to be initialized as much as possible before running ctors in side modules. The current setup lets us do:

* call relocation functions on the main
* call relocation functions on the sides
* call ctors on the sides
* call the `_start` function in the main - at this point we can't make any more calls to the sides, so they have to be set up already

A different implementation may want to do things differently, or be smart about which modules are initialized in which order.

I also wonder about `__wasm_apply_tls_relocs` being private... `__wasm_apply_data_relocs` is already public and I understand linkers are supposed to call it. What's special about `__wasm_apply_tls_relocs` that it gets a different treatment?

Anyway, an alternate implementation that sticks to the rule "every thread should call `__wasm_tls_init`" would be:

* `__wasm_init_memory` sets `__tls_base` to the area allocated by the compiler, but does not initialize it
* `__wasm_init_tls` can later take the `__tls_base` value and do its initialization, including calling `__wasm_apply_global_tls_relocs`

This is also compatible with what we want to do in the linker. However, this is a breaking change for both the linker and the libc code, so I'd like to avoid it if at all possible.

https://github.com/llvm/llvm-project/pull/149832