runtime: c-shared builds fail to load with dlopen with musllibc: `initial-exec TLS resolves to dynamic definition`

[charleskorn]

Splitting out from #13492:

@ansiwen's comment:

For what it's worth, compiled with -buildmode=c-shared I get:

sc_dlopen failed: Error relocating ./foobar.so: (null): initial-exec TLS resolves to dynamic definition in ./foobar.so

with

$ go version
go version go1.17.5 linux/amd64
$ cat /etc/alpine-release 
3.15.0
$ apk version musl
Installed:                                Available:
musl-1.2.2-r7                           = 1.2.2-r7 

I am still seeing a similar issue today with Go 1.19.

[heschi]

cc @golang/runtime

[mknyszek]

I suspect this is more compiler related (based on the other thread), so CC @golang/compiler

[charleskorn]

@mknyszek I see you've added the help wanted label. I've never done any work in the Golang runtime or compiler, but I'm happy to have a go at fixing this if someone can give me some pointers on where to start and a reasonable approach to take - is this something you can help me with?

[richfelker]

This is happening because go is producing shared libraries with initial-exec accesses to TLS objects defined in them. As the name implies, the initial-exec access model is only valid for accessing TLS objects present at initial exec time, not ones dynamically loaded later. So shared libraries can use it only if they are loaded at program load time as a dependency or via LD_PRELOAD, not if they will be loaded (directly or indirectly as dependencies) via dlopen. My understanding is that the golang compiler does not yet implement the dynamic TLS access models, so if that's still the case, fixing this bug depends on implementing that.

[jgowdy]

Is there a feature request for implementing the global-dynamic TLS model in Golang? This would be very valuable for my project.