Improve test_dylink_tls. NFC

[sbc100]

Make TLS variables static which fixes a linker failure when
building with -g (for example this test currently fails under wasm2g
and wasm0g congigurations).

Also, add two different TLS variables in each of the modules which
helps with debugging since only one of them will be at TLS offset 0.

[dschuff]

So I guess this doesn't actually test import and export of TLS, just that TLS variables work in main and side modules?

[dschuff]

wait but why does the link fail with the old version?

[sbc100]

So I guess this doesn't actually test import and export of TLS, just that TLS variables work in main and side modules?

Yes exactly, there is a TODO already in place to add TLS import/export testing.

[sbc100]

wait but why does the link fail with the old version?

This test currently fails with following error when building with -g:

wasm-ld: error: TLS symbols cannot yet be exported: `bar`
emcc: error: '/usr/local/google/home/sbc/dev/wasm/llvm-build/bin/wasm-ld -o side.wasm --whole-archive /tmp/emscripten_temp_gz91gwpy/side_0.o -L/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/pic /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/pic/crtbegin.o --no-whole-archive -mllvm -combiner-global-alias-analysis=false -mllvm -disable-lsr --import-undefined --import-memory --shared-memory --export-all --no-gc-sections --experimental-pic -shared' failed (returned 1)

I guess because bar is non-static symbol and we are linking with --export-all.

Its not clear to me why this doesn't also fail without -g but I think this change it worth landed given that it fixes a known failure. I'm currently working TLS import/export so I can investigate and I will investigate and fix that issue.

[sbc100]

wait but why does the link fail with the old version?

This test currently fails with following error when building with -g:

wasm-ld: error: TLS symbols cannot yet be exported: `bar`
emcc: error: '/usr/local/google/home/sbc/dev/wasm/llvm-build/bin/wasm-ld -o side.wasm --whole-archive /tmp/emscripten_temp_gz91gwpy/side_0.o -L/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/pic /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/pic/crtbegin.o --no-whole-archive -mllvm -combiner-global-alias-analysis=false -mllvm -disable-lsr --import-undefined --import-memory --shared-memory --export-all --no-gc-sections --experimental-pic -shared' failed (returned 1)

I guess because bar is non-static symbol and we are linking with --export-all.

Its not clear to me why this doesn't also fail without -g but I think this change it worth landed given that it fixes a known failure. I'm currently working TLS import/export so I can investigate and I will investigate and fix that issue.

I figured it out. The reason is that we have relocations of type R_WASM_MEMORY_ADDR_I32 in the debug info section which forces the address to be imported as GOT.mem.bar whereas the code section we generate __tls_base+R_WASM_MEMORY_ADDR_TLS_SLEB.

I guess on native platforms you would end up with dynamic relocations in the debug info section? But we currently don't support that. Even with TLS imports which I'm hoping to land this week I don't we can change the debug info sections to use global.get to retrieve addresses.. so I guess we need to find some kind of dyanmic relocation solution for DWARF?

[dschuff]

Yeah this change is fine. I just wanted to make sure we understood what's happening here so we pick it up when we're ready.

[dschuff]

I guess on native platforms you would end up with dynamic relocations in the debug info section? But we currently don't support that. Even with TLS imports which I'm hoping to land this week I don't we can change the debug info sections to use global.get to retrieve addresses.. so I guess we need to find some kind of dyanmic relocation solution for DWARF?

Ick :(